Connecting Business Architecture to Solution Architecture
Many organizations treat solution architecture as a application development or project delivery role. The reality however is much more complex. In business architecture and enterprise architecture circles we discuss the strategy to execution goals of the architecture team. In reality the strategy or transformation which make this such a hard process is delivered through annual business and technology solutions, whether they are marketing campaigns, new products or technology structure changes.
The solution architect is responsible for the getting the strategy to match with execution and yet they often do not get a chance to review, much less buy off on the strategy, outcomes or reality of the solution. To do so it is absolutely essential that they be fully connected to the business and enterprise architecture initiative and not simply glorified technical leads. Effective solution architects are a part of delivering against the business architecture and therefore must be bought off on:
- Business Architecture Artifacts
- Capability Models
- Strategy Map - Balance Scorecards
- Business Model Canvas
- Benefits Dependency Networks
- Value Chains
- Business Process Model
- Business Organization
- Value Management Models (means of estimating success in value capture)
- Business and Technical Target State Models/Documents
With a connected architect organization (more to come on this), the architects are in constant communication, regardless of reporting structure and, therefore, are ahead of the planning and project lifecycle. This kind of model treats ALL architects as professionals within the strategy and execution lifecycle and requires a deep understanding of inputs and outputs of business to solution to business architecture. Without the deep connectivity of architecture inputs and outputs you can expect the following results:
1. Business architects will be at risk for lack of a) business value contribution due to low level of execution accuracy in transformation and b) lack of technical outcome understanding related to long-term target state mismanagement.
2. Solution architects will lack buy off and therefore commitment to project outcomes.
3. Solution architects will retain technology only skills, lacking a clear understanding of spirit of the business direction (customer outcomes) as opposed to the letter of business direction (requirements) leading to silo and poor execution with major technical drift.
4. Solution and business architects will work at cross-purposes and often view each other as lacking direction, capability, or understanding.
There will be a significant group of people saying things like, "Oh that group isn't REALLY an architecture team." This results in credibility challenges throughout the lifecycle.
The way to fix this is internal architect community and a fully realized engagement model which includes all architects in the organization. I will be writing a series of posts on how to execute on both of these within your company in the near future. In the meantime keep your eye out for the upcoming Iasa ITABoK 3.0 which will provide a detailed guide to capabilities, engagement model and tools and techniques.