I’m in San Diego attending the Drug Information Association conference with the goal of getting smarter in the functional areas that make up a bio-pharma company. I’m here with two exceptional architecture colleagues which means that most meals have consisted of us talking shop.
During dinner tonight, we were discussing the importance (or imperative, really) of having a central business champion that can envision what they need and communicate that vision to the technical team. The technical team shouldn’t be telling the business what their vision is.
Within that conversation, we talked about the value of having good business analysts who deeply understand the business and are in the position to offer actual improvements to the processes they uncover and document. I then asked if it’s valid to hijack many of the attributes that architects think about in the confines of a technical solution, but also have them applied by a business analyst to a business process. Maybe it’s crazy, but on first pass, most of the solutions architecture things I spend my day thinking about have direct correlation to what a good business process should address or mitigate as well:
- Scalability. How well does my process handle an increase in input requests? Is it built to allow for us to ramp up personnel or are there eventual bottlenecks we need to consider now?
- Flexibility. Can my process support modifications in sequencing or personnel? Or did we define a process that only works in a rigid order with little room for the slightest tweak?
- Reusability. Is the process modular enough that an entire series of steps could be leveraged by another organization that has an identical need?
- Encapsulation. If I’ve chained processes together, have I insulated each one from another so that fundamental internal modifications to one process doesn’t necessarily force a remodeling of a connected process?
- Security. Have I defined the explicit roles of the users in my process and identified who can see (or act on) what information as the process moves through its lifecycle?
- Maintainability. Is the process efficient and supportable in the long term?
- Availability. If someone is sick for two weeks, does the process grind to a halt? What if a key step in the process itself cannot be completed for a given period of time? What’s the impact of that?
- Concurrency. What happens if multiple people want to work on different pieces of the same process simultaneously? Should the process support this or does it require a sequential flow?
- Globalization/localization. Can this process be applied to a global work force or conversely, does the process allow for local nuances and modifications to be added?
Just like with solutions architecture, where you often may trade one attribute for another (e.g. “I’ll pick a solution which give up efficiency because I demand extreme flexibility”), the same can apply to a well-considered business process.
So what do you think? Do the business analysts you work with think along these lines? Are we properly “future-proofing” our business processes or are we simply documenting the status quo without enough rigor around quality attributes and a vision around the inevitable business/industry changes? I’ll admit that I haven’t done a significant amount of business process modeling in my career so maybe everyone already does this. But, I haven’t seen much of this type of analysis in my current environment.
Or, I just ate too much chicken tikka masala tonight and am completely whacked out.
Richard Seroter's Architecture Musings 
Nicely put. I’m trying to figure out where you’d put “forward looking – is the process going to support near-term business environment changes?” There are a lot of sub-components of this that we do in the software space. For example encapsulation, especially, enables future changes but is not forward looking itself.
Indeed, you are a great writer with good memory!
From our discussion earlier at the dinner table, you know my answer to the question – yes, attributes of Software Architecture seem to be very much applicable to Business Process Architecture.
I must confess – I haven’t seen any business organization formally or systemically apply this in designing their business processes. Experienced business process owners use them unconsciously. In my personal experience, I have used them as a technique to make business process owners think about trade-offs (e.g Is this process/system expected to change frequently and quickly with external business environment? Is it critical for us to keep the agility even with some sacrifice of efficiency?). Most often, I have received very positive response!
Carrying these thoughts further, I wonder if this attributes also apply to “building” architecture. Are these attributes, essentially attributes of any “architecture” discipline and not specific to software or business process?
Also, if the software architecture attributes are portable to “business process” world, are there design patterns from software world that may be applicable to business process design?
Here is a link that showed up at the top in Google search for “business process design patterns”- http://www.businessprocesstrends.com/publicationfiles/05%2D06%2DWP%2DBPMProcessPatterns%2DAtwood1%2Epdf
Great post. We’ve been delivering a software based PBX for years and have just recently stepped into the business process space. Your correlations between architecture and BP are similar to what we saw on the communications side. While we approached it from the standpoint that the attributes of routing, tracking and delivering a phone call are present in most business processes, it’s interesting how many of your bullets associated with software architecture match our own business process topics.
Scalability, Flexibility, Availability and all the other ‘itys come into play whether posting records to a DB, routing a call to the right person, or getting an Insurance form to the right person to act upon.
Having now seen the connection between software architecture, business process and communications, I will be sure to order in chicken tikka masala for our next design meeting.