To architect for business value, we need to rescue business architecture from the process optimization prison that so many methodologies relegate business architecture. They divide the enterprise into slices - information, application, business, infrastructure, integration, etc. - treating each as equal branches of the architecture, often with their own architect. These business, information, application, and technology architects then develop the deliverables specific to their architectural domain, slap them together in a PowerPoint and voila! An architecture!
Okay, perhaps I'm oversimplifying a bit. More mature architecture practices understand that collaboration is a critical to successful architecture. In less mature practices, this leads to a comical situation in which architects are prevented from seeing the information that sits outside of their piece of the world. This is perhaps the logical conclusion of methodologies that overemphasize frameworks to categorize architecture information.
Getting value from architecture means not simply answering what information we need but also when. Many definitions of architecture define it as a bridge between business strategy and IT. A methodology that doesn't talk about how that gap is bridged - what information and when - will have difficulties succeeding. Similarly a business architect who is narrowly focused on business process, organizations , and roles may have something interesting to tell the business sponsor but risks not being able to tell a complete story.
The business architecture isn't about a narrow slice of business-relevant information, it's a complete view of the architecture at an abstraction that is appropriate for the business stakeholder. I have yet to meet a business leader who wasn't materially interested in the technology that supported their organization. They might not care that the interface that connects their reporting system to your enterprise data warehouse uses SQL queries but they do care that they are connected.
I believe that the business architect is the frontline for the architecture team in working with the business to connect the strategy to the operational execution of that strategy. The business architect - working with other domain architects - provides a perspective to the business stakeholder to make decisions about what investments to make.
At this level, the level of technical detail required is just enough to inform the investment decision. It does not require in-depth analysis of application interactions or even process decomposition.
When we move from investment planning to solution planning, design, and delivery, that's where greater detail around the processes, information, applications, and technology becomes more important and more traditional architecture methods take more relevance.
It's a level of abstraction, not scope of information. In other words, the business architecture is the business's perspective of the architecture.
Recent Comments