Can Software Architecture Attributes Also Be Applied to Business Processes?

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.