One of my current research projects is to define how EA teams capture and express business strategy. Early in the process I am finding a lot of variation in how organizations articulate strategy. In my preliminary interviews I have heard three basic definitions of strategy:
What is the key to effective enterprise architecture? In a word: influence. I rarely see an EA team that can’t build a reasonably good architecture, but I also rarely see an EA team that can successfully drive support for even the best of architectures. The most elegant architectures are worthless unless they are widely adopted and utilized. We don’t need more elegant architecture models; we need more eloquent architects.
Over the past few years I have asked hundreds of architects two simple questions. First: “What is more difficult - building architecture or implementing architecture?” Every single architect without exception tells me architecture is much harder to implement than to build. My second question is more telling: “Where do you spend the majority of your time?” Their answer: “Building architecture and my architectural skills.” Even though EAs clearly understand the problem, they don’t address it. Why is that? I think it is because deep down inside, they don’t want to.
Building organizational influence is long and difficult work. It requires an entirely different skill set than architecting. The focus is on people and relationships rather than technologies and concepts. Most architects don’t feel comfortable here. Instead of acknowledging reality and dealing with it, often architects try to avoid it by putting the problem on someone else’s back. “EA can’t succeed without executive sponsorship.” “Someone needs to give us more authority and control.” The fact is, very, very few EA teams actually get anything close to this. The majority don’t even get significant support from their CIO. And yet, somehow, many succeed. How? By building personal and organizational influence. The bottom line to EA success is organizational impact. How much are you having?
When digging into the data from September 2009 Global State Of Enterprise Architecture Online Survey, I found an interesting correlation in the data: Survey respondents who reported a high degree of business and IT process standardization also reported that EA was more effective and more influential within the organization. As the level of standardization decreased, so did EA effectiveness and influence. Just take a look at this sample data from a report that recently went live on our website:
Why does this correlation exist? We’ve been saying (and most clients have been agreeing) that process standardization is a keystone to effectiveness across all areas of IT: apps, infrastructure, PMOs, you name it. When I look at IT organizations in my research, those that focus on standardizing processes or that live in an environment of highly standardized business processes tend to be doing a better job.
But simply being more standardized can’t be the “secret sauce” for EA success. There must be something that standardization does to an organization — a window or door that it creates — that enables IT functions such as EA to get better at what they do. Based on deeper analysis of our data, this is my hypothesis:
A number of Forrester analysts have been collaborating on a series of Tweet Jams on topics related to data management. The last session was on BI, and the next one up is on MDM. These are very lively sessions involving many points of view on some quite provocative topics. I'm pasting in text from analyst Rob Karel's blog post on the upcoming MDM session on July 20 in case architects who read our EA blog don't read the business process blog where Rob posts. For most of the EA folks I have spoken with lately, information architecture and MDM are very relevant -- not to mention thorny -- topics. I hope you join us for a great discussion!
Rob's description of the session:
Many large organizations have finally “seen the light” and are trying to figure out the best way to treat their critical data as the trusted asset it should be. As a result, master data management (MDM) strategies, and the enabling architectures, organizational and governance models, methodologies and technologies that support the delivery of MDM capabilities are…in a word…HOT! But the concept of MDM - and the homegrown or vendor-enabled technologies that attempt to deliver that elusive “single version of truth”, “golden record”, or “360-degree view” - has been around for decades in one form or another (e.g., data warehousing, BI, data quality, EII, CRM, ERP, etc. have all at one time or another promised to deliver that single version of truth in one form or another).
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.
Broadens the definition of metadata beyond “data on data” to include business rules, process models, application parameters, application rights, and policies.
Provides guidance to help evangelize to the business the importance of metadata, not by talking about metadata but by pointing out the value it provides against risks.
Recommends demonstrating to IT the transversality of metadata to IT internal siloed systems.
Advocates extending data governance to include metadata. The main impact of data governance should be to build the life cycle for metadata, but data governance evangelists reserve little concern for metadata at this point.
I will co-author the next document on metadata with Gene Leganza; this document will develop the next practice metadata architecture based partially but not only on a metadata exchange infrastructure. For a lot of people, metadata architecture is a Holy Grail. The upcoming document will demonstrate that metadata architecture will become an important step to ease the trend called “industrialization of IT,” sometimes also called “ERP for IT” or “Lean IT.”
In preparation for this upcoming document, please share with us your own experiences in bringing more attention to metadata.