I am frequently asked what makes a good architect and, more often now, what makes a good business architect. If I were hiring a business architect, here is what I would look for:
A sound understanding of business principles and concepts. Most IT types think understanding the business is all about understanding the business processes, but this is not what business leaders are interested in. Business architects should understand how the market context affects the business, how value is created, what differentiates their company from its competitors, and how products are created, marketed, and sold. They should have a good understanding of how business strategy is developed – even if it is never articulated.
An ability to think about business processes outside of the technology context. Even business people have a hard time with this. I have had more than one business architect share his frustration with business project people who continually talk about business process in terms of how their applications work. Though a business architect needs to understand how to leverage IT for business value, he needs to be able to draw a wide, heavy line between business processes and the technologies that enable them.
A really strong consulting mindset. Building a good business architecture is more about listening and hearing between the lines than selling a concept or framework. At the end of the day, the successful business architecture will be one that resonates with business leaders. Business architects should see themselves as business consultants looking for problems to solve.
During the first 8 minutes or so, the presenter makes a number of excellent points about how architects have abdicated their power to act. (He actually calls us cowards.) The rest of the presentation is an amazing example of what happens when architects take the responsibility to make their creations come to life. As with most TED videos, it is well worth the 18 minutes it takes to watch it.
Mike and I had been talking about the role of architecture and how architects respond to their organizational context. For many architects there is a big divide between representation and what Prince-Ramus calls agency – taking action. Too often we create “genius sketches” but accept little accountability for making them real. We expect the organization to embrace them and do the “easy” work of implementation. I’ve got news for you. Creating the architecture – those genius sketches – is the easy part. Getting the organization to embrace them and make them its own is the hard part. Of course we know that; we just don’t act on the knowledge.
By way of example: I occasionally recommend to architects that they need a small team of developers to implement some parts of architecture like an ESB or SOA components. I get the “we’re architects man, we don’t do that” response. Well ... maybe we should. Maybe we should “own the problem” instead of pointing our finger at others
A client recently requested a presentation on the future of enterprise architecture. I always enjoy these types of topics, partly because they give me some latitude to think creatively but also because they make me think about things that don’t come up that often in my day-to-day problem set. In the presentation I covered a lot ground about the current state of EA, trends affecting EA’s future, and what EAs should focus on to ensure future success. Business architecture played heavily in my view. But the bottom line can be summarized in five scenarios. Here are the five scenarios I came up with and my take on each.
Scenario 1: EA disappears as a unique function. I think this scenario is inevitable in the long run (but here I am talking about 20 to 30 years) as we move to purchased applications (“there’s an app for that”) and Moore’s law continues to drive down the cost of hardware to the point where performance/capacity/reliability/etc. issues all but disappear. But in the near term (let’s call it 10 years) I think this is a highly unlikely outcome. Because, even though EAs struggle to demonstrate value, the promise of EA value among CIOs remains strong.
The current metaphors for EA can be useful at a conceptual level to help non EAs understand what all the fuss is about. Most people understand the role of the building architect and the city planner and can make at least a rough association to what enterprise architects do. But many architects take these metaphors much too literally and much too seriously. They try to fashion their practice to align with the metaphor instead of taking the metaphor concept and creating a new way to apply it in their IT or business space.
The enterprise architect as building architect
I use this metaphor myself when I am talking with non architects. Conceptually, it is a very rich metaphor that almost everyone can identify with. Even though most people have never seen a complete set of blueprints, they have seen enough examples to get the point. Unfortunately, this metaphor breaks down pretty fast.
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.
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.
When I was searching for input to my first business architecture research report titled “Business Architecture’s Time Has Come” in October of 2008, I had a hard time finding true business architecture practitioners to participate in the study. To be sure, there were lots of EAs thinking about business architecture, but very few really doing business architecture.
Earlier that year I had facilitated a group discussion about the current state of business architecture at an EA conference. There were more than 30 people in the room, and the discussion was lively. Much of the first half hour focused on what business architecture really meant and how it should be applied. There were a wide array of positions and some very impassioned exchanges. To shift the discussion to more practical areas, I asked “Who has an active business architecture practice?” To my surprise not one person in the room raised their hand.
What a difference a year makes. Our 2010 research shows that 40% of organizations now have an established business architecture program. And most of the rest are working toward creating one. For a large majority of EA teams the question has shifted from “When should I start my business architecture effort?” to “How do I get business architecture moving?” Forrester’s 2010 EA Forum had a track dedicated to enterprise business architecture. I presented or facilitated three business architecture sessions that were all heavily attended with lots of active participation. Some of the interesting ideas that surfaced during forum discussions were:
Creating and demonstrating value continues to be a critical issue for many EA teams. Forrester believes that architects can have greater impact by tightly tying their activities to value levers their organizations care about and demonstrating how EA supports IT goals. Why does value continue to be a top-of-mind issue for EAs? Why don’t organizations recognize and appreciate EA’s value? Forrester is conducting a research initiative to assess the state of the market and identify best practices successful EA teams use to create and demonstrate value.
We are asking our blog readers to contribute to this client-driven research by taking a 16 question survey. To thank you for your time completing this survey, we'll provide you with the survey results so you can see how your responses compare with others, as well as the chance to participate in a 30 min teleconference with Forrester analysts who will tell you 'what it means.’
I have been thinking lately about the differences between wants and needs and how they shape our lives. Most of us are pretty clear about what we want and go after it. What we need is a little less clear. Sometimes we know what we need but avoid it (“I want that chocolate brownie with vanilla ice cream smothered in fudge sauce” versus “I need to lose some weight”) and sometimes we don’t know what we need and just let our wants drive us (I want to yell at my staff – so I do, but what I need to do is listen to them).
I think what drives many of EAs’ problems is not misalignment with organizational needs (though some of the more theoretical EAs certainly are misaligned as they seem to think architecture is the center of the universe). The real problem is not clearly understanding the difference between what an organization needs and what it wants and having the ability to manage the disparity between the two.
So what do organizations want? For the most part business units and the IT development teams that are aligned with them want to develop solutions that they are comfortable producing. This translates into using technologies and techniques they have been successful using in the past. EA wants them to do it differently and that difference always introduces risk. The risk may be real or imagined, but it doesn’t matter to the PM. Both are real to him. So bottom line, the organization wants to continue using the methods of the past because they are the best predictor of success they have.