Set Business Architecture Goals BEFORE You Start

Starting a business architecture initiative with the goal of creating business architecture is the surest path to failure. Before you take your first step into business architecture, think long and hard about your goals, what value you are trying to create for the company, and your current ability to execute. The successful business architects I work with have a crystal clear view of the problems they are attempting to solve and the primary stakeholders for that problem set. They typically start with a narrow focus on a specific business problem and widen their approach as they make progress. While the more theoretical architects out there make strong arguments about what business architecture “should be” - the reality seems to be quite different. Business architecture success is creating an architecture that works – not one that adheres to an idealized business architecture model.

Forrester has identified seven business architecture goals along with their primary stakeholder. Business architecture practices can attack multiple goals simultaneously, but keep in mind that a narrower focus leads to faster value delivery.  



Primary stakeholder

Business transformation

Create new business capabilities and/or leverage existing capabilities in new ways to create new business value

Senior executives and business strategists

Business effectiveness

Improve existing business capabilities to better serve the customer or significantly enhance business operations.

COO and line of business executives

Business efficiency

Improve process efficiency and reduce functional overlaps to reduce operational costs and complexity

COO and business managers

Business-IT alignment

Improve goal, strategy, investment, and resource alignment between IT and business units

CIO and business executives

IT effectiveness

Improve IT’s core capabilities to serve the business needs

CIO and IT executives

IT efficiency

Improve IT’s cost performance through process improvement and technology standards

IT managers

EA effectiveness

Improve EA performance through better understanding of business and IT goals and strategies

Enterprise architects

My advice to new business architects? Think big – start small – move fast. First figure out what you would really like the business architecture to be. Then drop back to what you actually can accomplish in the near term given your current skills and organizational context. Set reasonable goals and with every success, move the ball forward. Keep in mind that just like everything else in business, value is everything. The more value you add, the faster you can move.

If you have a success story about growing business architecture or a challenge you are struggling with, let me hear from you.


Architecture IS the goal of an architecture initiative

Starting a constructional architecture initiative with the goal of creating architecture of a building is the surest path to failure. Nonsense? Of course. Evident? Sure. Why not so about Business Architecture? Just because we understand the former much better than the latter.

Had we thought a bit, we’d understand that business beacons are dictated mostly by the market and thechnology. The goal of BA is to support these goals in the best possible manner. Even the perfect BA cannot save wrong Business Model (EBM), while bad BA could crash even the best EBM.
So, when we start a BA initiative, we should have in mind only to do it methodologically correct. Then, the very process will lead us to the right support of the market and technology-led business goals.
This amorphous ‘long thought’, mentioned in the blog IS the process of the creation of the correct BA

Just don't hold on to them to tightly

You definitely need to "Set Business Architecture Goals BEFORE You Start" but you need to be flexible. Business architectures are usually more stable than other areas, but our understanding of them may not be. As the quote goes "all models are wrong but some are useful".

All models are wrong

Charles - Great point. We spend so much effort creating our models that we often forget that they are representations of real things not real things themseles. Just as a picture of me isn't me. A better way to think about it might be that a model is an approximation of something. The more we know about the real thing, the more accurate our model. Implication? As we learn, our model necessarily has to change.