1. Business architecture is a critical input to IT planning, technology architecture and business solution delivery.
2. Technology trends and IT capabilities influence business design choices in the realms of capabilities, value chains, processes, and channels.
3. Business architecture provides the mechanism to clearly illuminate how strategy, processes, business structure and staff can best be utilized to deliver reliable and cost effective operations. With this clarity business can enable new functions and services, with the right resources and technology, effectively and efficiently.
4. Business architecture can help organizations analyze key value chains. Organizations can eliminate duplicate operations, processes and technologies across business units and functions. Business architecture provides the methods to analyze and plan how the organization should morph its structure, processes, technology and staff.
5. The most likely origin of a business architecture practice is within IT.
It is difficult to see anything here that wasn't included in the Business Systems Planning and Business Engineering methodologies I first saw in the 1980s - for example, as a front-end to such methodologies as Information Engineering. Nowadays, Michael Porter's value chain concept is taught in high school business studies; so unless business managers are really thick, they are not going to need help from IT folk to "analyse key value chains".
Actually, there are some more advanced business design choices where business architecture has a useful role to play, and where some IT people might have some relevant aptitude, but the SOA Consortium doesn't mention any of these. I see the real challenge for business architecture being to appreciate the economic and social impact of structure. And by structure, I don't just mean the kind of line-and-box diagram or simplistic block diagram that most so-called architects produce, whether in PowerPoint or some cheap modelling tool, but something that reflects the real complexity of the business.
So what are these "business design choices" then? Well, this is a topic I've been talking about for many years, going back to my 2001 book on the Component-Based Business. Here are some critical ones, all of which I've discussed on this blog before, as well as in articles for the CBDI Journal.
1. Coupling. Which "components" of the business need to be closely aligned (tightly coupled) and which "components" should be autonomous (loosely coupled)? How is an enterprise governed as a system-of-systems? How do we reason about the properties of the whole enterprise?
2. Differentiation and Integration. Where does standardization make sense, and where should requisite variety be deployed? This question goes back to the work of Lawrence and Lorsch (see summary here), and has recently been rediscovered (in slightly different terms) in the book Enterprise Architecture and Strategy.
Operating Model Quadrants - Source MIT CISR.
3. Business as a Platform. A business provides a set of services to its customers. There is a strategic choice between a high-volume generalized platform, which takes a small slice of a large amount of activity, and a lower-volume specialized platform, which takes a much larger slice of a relatively smaller amount of activity. So for example, how does a telecoms company create value-adding services on top of the basic calling services (which are getting continually cheaper, thus eroding core revenue) without losing the economics of scale.
4. Edge Organization. What are the structural implications of turning your business upside-down and inside-out to address the dynamics of the demand environment?
5. Viable Business. What structures are required to support the intelligent organization?
So there is a set of really interesting and important issues here, which some of the smarter business people in the more complex industry sectors (aerospace, telecoms) are already trying to tackle. There are some new and emerging techniques for tackling these complex problems, including Asymmetric Design, as well as some older but underused techniques. However, I don't yet see much evidence of enterprise architects stepping up to the real challenges of business architecture.
Related Post: Differentiation and Integration (May 2010)
4. Edge Organization. What are the structural implications of turning your business upside-down and inside-out to address the dynamics of the demand environment?
5. Viable Business. What structures are required to support the intelligent organization?
So there is a set of really interesting and important issues here, which some of the smarter business people in the more complex industry sectors (aerospace, telecoms) are already trying to tackle. There are some new and emerging techniques for tackling these complex problems, including Asymmetric Design, as well as some older but underused techniques. However, I don't yet see much evidence of enterprise architects stepping up to the real challenges of business architecture.
Related Post: Differentiation and Integration (May 2010)
Richard,
ReplyDeleteInteresting post. Personally, not as the paper editor, the point I find most compelling is:
"Business architecture is the formal representation of business design, with the intent to apply the business architecture information and supporting techniques to optimize the business design, and facilitate on-going change."
I think we agree that change is continuous. A high functioning Enterprise Architecture practice should lay the foundation for continuous change.
I agree with you that Business Architecture isn't a new idea, nor are the underlying techniques. Here, what's interesting to me is the lack of uptake within organizations, not just EA.
I definitely see a branding issue, particularly with the word "architecture". And of course, IT being the champion is problematic.
In my own practice, I'll be looking at the above points: business architecture information & techniques to enable continuous change; and the branding issue.
I saw your tweets this morning; I look forward to your work on Organizational Intelligence.
Best,
-brenda
Hi Brenda.
ReplyDeleteThere is certainly business design going on in all sorts of organizations, but IT people aren't always invited to participate.
Obviously there is no point producing a formal representation that fails to support practical reasoning about complex business design choices - such as the issues I outlined above. So if IT-centric enterprise architects trot along to the strategy meetings with BPMN or ArchiMate diagrams, they may not be taken very seriously.
New lenses for business architecture. Maybe that's another book I need to write. Not enough hours in the day.
As Brenda says, "a high functioning Enterprise Architecture practice should lay the foundation for continuous change".
ReplyDeleteBut surely that means you have to have a formal representation that encompasses change, based on a theory of time and continuous change. Not just AS-IS and TO-BE models, which is all most enterprise architects can manage.
Precisely --> "But surely that means you have to have a formal representation that encompasses change, based on a theory of time and continuous change. Not just AS-IS and TO-BE models, which is all most enterprise architects can manage."
ReplyDelete