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.
This week, I talked with an IT group that had an organizational unit called “IT Business Management” with the charter to help IT run like a business. Well, it’s about time! I know a lot of IT strategists and consultants push the idea that IT should be an integral part of the business and shouldn’t be thought of as an independent organization. And that may be what it should be, but it’s not what it is today. Today’s IT is by and large a separate organization even when it is distributed across multiple business units.
In many companies IT is a large, complex business unit in its own right with a significant chunk of the business’s operating budget. When CIOs control hundreds of millions of their company’s dollars, shouldn’t they be thinking about what business value they are delivering on that capital? And isn’t a great way to do that by looking at and managing IT like a business?
When I first started talking about building a capability model for IT, I received a lot of blank stares and comments like: “Why would anyone want to do that?” My question is: ”Why wouldn’t everyone want to do that?” IT execs spend a significant portion of their time managing business demand to fit current IT resources but very little time improving IT’s ability to respond to increasing business demand. An IT capability model provides an excellent starting place to view IT like a business and identify what is most important to IT’s success and where to invest the few dollars we have to make it better. Many architects I talk with are having real success with business executives using capability maps to focus the conversation and their attention on what parts of the business are most important. With an IT capability map, we can do the same thing for IT.
In developing a technology strategy for your organization, what will be your basis for deciding which technologies to pursue, when to pursue them, and how to implement them? In other words, what will be the foundation for your technology architecture and strategy? In considering this question, I assume we agree that technology strategy should directly support improvement of business outcomes, both now and over the long haul. To provide for the long haul, your technology architecture and strategy must be crafted to support a continuous stream of business change, both small incremental steps and large radical shifts.
Your strategy could begin with a list of hot technologies — perhaps even ones that business colleagues are clamoring for — but how would you know which of them would lead to the most important improvements in business outcomes? You could begin with your top executives’ current business plans and strategies — which would clearly address today’s priorities for improving outcomes — but over the long haul, business plans change, sometimes dramatically, making them an unstable foundation for technology strategy.
Since the goal of technology strategy is to improve business outcomes, let’s refine the question with that as our focus: What basis for technology architecture and strategy:
(a) Aligns best with the ways that business leaders conceive, plan, execute, and measure improvements to business outcomes,
(b) Provides the best structure for building technology implementations that align with and facilitate the ways that businesses change both now and over the long haul, and
(c) Best guides the prioritization, planning, architecture, design, and usage of technology within business improvement projects?
Business first!Whether your goal is business transformation, IT effectiveness, or just a better technical architecture, you need to start with a business-only view of your business architecture. If not, you will struggle with getting business sponsorship, and just as importantly, you will struggle with your own understanding of the business.
Until EAs convince business people that they do in fact understand the business, business leaders aren’t going to get excited about business architecture. This is basic sales 101- first understand the customer. To be sure, business cares about technology. In fact, they care about it quite a bit. Business leaders clearly understand how important technology is to their business success. What they are not so sure about is if IT understands the business. If the business was confident IT understood them well then we wouldn’t be seeing all the issues resulting from business people engaging with technology vendors and making technology decisions without IT’s input. Instead, they would be saying: “IT knows what I need, go talk with them.”
Architects that don’t collaborate with their business compatriots when building business architecture are finding it difficult to connect with the business. I have been talking with a number of architects lately that are getting push back from the business. What is the business saying? “That’s an IT thing.” Why are they saying that? Most likely because it is an IT thing - an IT centric business architecture.