I have to ask myself if these enterprise architecture teams understand what they are missing.  The enterprise perspective is embodied in activities and deliverables that are not only enterprise-wide in scope and objectives, but also forward-looking, strategic, holistic and business-driven.  Relative to solution architecture (SA), the goal of EA is to provide this enterprise perspective so that SA’s can guide the tactical, technical, siloed project-oriented activities to fit with the long term business and technical direction of the enterprise.  Without the enterprise perspective, the SA’s are only guiding projects to fit within the technical best practices and emerging trends from the perspective of an individual SA or SA group.  Valuable, yes, but not EA.

But there is an even greater impact to an organization of an EA without an enterprise perspective, and that impact is felt by other  planning groups relying on EA to provide that long-term, holistic, business-driven, strategic view.  Budgeting, portfolio management, change management, strategic planning, sourcing, and operations planning all tend to happen with an eye on the short-term and tactical.  Without EA fulfilling its obligation, these plans are likely to be inconsistent, abandoned quickly, lead to waste, and ultimately, diminish confidence in the IT organization, the CIO and the IT management team.

The excuse that many EA groups are using is that there is a focus on the short term because of the economy, resource shortage or lack of business strategy from the enterprise leadership.   This excuse might hold weight for organizations just getting started with EA in the last 2-3 years, but what about the EA teams that have been operating for 5 years or more and NEVER developed the EA perspective.  Simply put, it is usually a lack of leadership and understanding of what is needed to create the enterprise perspective.  We counsel organizations to do the work to create a baseline of the enterprise perspective and use that to help leadership understand what the enterprise perspective is and how they can use it.  Good leaders will make use of it, and understand that now is the time to be looking forward.

The term “anchor model” represents a concept, not a specific format.  In our experience there is no such thing as the perfect template for an anchor model. The model must resonate with the broadest audience in as natural a way as possible. Therefore, the model should be in the language of the business it is depicting and is “good” only if it is meaningful to that organization. We have seen wildly different representations from different companies, yet each turned out to be exactly the right model. It’s one of those “you know it when you see it” phenomenon. When it is right, the model just makes sense.

Anchor models are basically top-level context diagrams describing the “enterprise”. They go by various names: company on a page, enterprise value network (EVN), concept of operations, operating models, root models, etc. These diagrams serve multiple purposes:

• As a consistent view of the company – a context for common understanding, language/terminology, etc. It allows everyone to get on the same page in the simplest, most direct way possible, representing a “big picture, enterprise view”.
• As a root for other derivative models (business, information architectures, business capability portfolios, etc.)
• As a credibility building tool for the IT executives in interactions with their business counterparts
• As a base model to super-impose various information systems, exposing overlaps, duplication, etc.

Creating a “good enough” initial anchor model is more art than science. It is a people-driven, collaborative exercise. A “starting point” model created by a sponsor usually helps kick off a productive session. We consistently observe several behaviors associated with the process, both good and bad, and have several tips to help you. Here are just a few:

• Anchor models can be controversial and are challenging to create. Don’t let that stop you from trying.
• Find passionate, business-knowledgeable people to start. Ideally, an anchor model should be something created by the business, not IT. An EA group is often the instigator to its creation and should act as catalysts to the process and not owners of the model.
• Not everyone is going to be happy. Someone will always object to something in the diagram, and the tendency is to just “make it a little better”. Our advice, work in a small group and time-box the activity. We suggest a few hours initially.
• Keep it simple, simple, simple, including only the significant parts of the organization. Resist the tendency to try to include everything a business does.
• Look at value networks, internal and external to the organization. Expose internal functional blocks, flows of information and services in/out/between them. Include the full range of external stakeholders and the interactions with them in the diagram (customers, suppliers, partners, regulators/government, etc.)
• Catalog your desired “functional hierarchy” to understand the main business functions performed. Avoid organizational constructs (departments, divisions, etc.). They are fluid and will undoubtedly change. Make your models as timeless as possible.
• Relationships are at the heart of anchor models. Understand the flows of information (not data models) and how functional elements relate.
• Timing is everything. We have seen good anchor models get no traction when presented to the wrong people at the wrong time.

There are many more tips that we can suggest. If you have a successful anchor model that resonates with your business, let us know. We’d like to hear your experiences and will share any other general pointers back to the community.

A strong anchor model, once complete, appears so obvious that many wonder why it was created. But that misses much of the point. It is the process of creating it that often yields the highest value.

We’ll review the findings from the A&G 2011 Year-End Survey, discuss trends we see shaping the role of enterprise architect going in to 2012, and answer listener questions.

Follow this link to the Architecture and Governance Website for more information and to register.

If you don’t know the answer to this, how can you expect others to understand EA?

This is a simple question, but we are looking for comments from your readers to help others (without their answer) come up with the answer that meets their situation.  While everyone probably has a unique approach to the process, organization, and deliverables for EA; we find that the objectives of EA are similar across organizations.  You may not currently be fulfilling the reason why you are doing EA, but you have to at least know what you are TRYING to do.

Let us know by your comments, Why are you doing enterprise architecture?

Tim will be presenting “Expanding Enterprise Architecture into the Business.”

The ultimate promise of Enterprise Architecture has always been the alignment of business and IT strategies, activities, assets and direction.  In order for EA to bridge the gap between the desired business future state and the work that must be done to achieve that future state, EA must evolve to include a business architecture sponsored by business leadership and developed by business professionals.

Tim will facilitate a discussion on the many facets of business-enabled EA, while also adding their experiences relating to the challenges of approaching the business, how EA and ITA work together, the goals, organization and outputs of a business enabled EA approach and how to get started.

This is an invitation-only event, so if you are going to be in the Atlanta area Dec. 13th, click here to get more information on the event and how to register your interest in attending.

Hope to see you!

If you are trying to avoid an overly tactical focus for your BA efforts, here are some suggestions to consider:

• Dedicated BA Resource.  A dedicated resource, not assigned to specific BA initiatives, but also not holding a full-time non-BA position is probably not feasible in many organizations.  However, those going through significant transformation efforts could easily justify a resource to keep pushing the transformation agenda, overseeing the BA initiatives, maintaining a focus on future change, and organizing and managing the BA virtual team.  If a full-time dedicated resource is not feasible, consider finding a leader who can dedicate some time to the effort, 25-40% minimum, while not getting deeply involved in individual BA initiatives.
• Strategic Agenda Items for Regular Meetings.  Most BA groups have regularly scheduled meetings, weekly, monthly, bi-monthly, etc.  By having every third or fourth meeting focused on new strategies, new technologies, new changes, rather than ongoing initiatives; the group will still be able to push the transformation work forward, while also continuing to architect the future business.  Another alternative is to always have at least one agenda item that is of a strategic, future oriented topic at each meeting.
• Maintain a Portfolio vs. a Project Perspective.  Rather than providing oversight to individual projects and implementation initiatives, focus on providing input to the investment decision-making function(s) of the enterprise, and track the overall portfolio’s progress against expected strategic outcomes.  Leave the cost, budget, resource, and schedule issues to the project management staff.

All of these suggestions are not new.  They are the same kind of actions that successful ITA groups have been employing to maintain a strategic perspective for years.

First, what do I mean by “style” and by ‘substance”? (note: I chose those words because it sounded like a catchy blog title) For the sake of this article, I define “substance” to be the “work product” of the team as viewed by EA consumers wanting hard deliverables like frameworks, models, standards, roadmaps, strategy papers, and other related content. “Style” refers to “how” the team works with the rest of the organization in creating and utilizing their content: engaging business and IT leadership, fostering a collaborative environment; choosing communications vehicles, the words they use, and the “posture” of how they present themselves to the rest of the organization.

Many EA teams disproportionately direct more effort to the substance of the work than to building a sense of ownership and socializing the desired changes. In essence, they under serve the “style” elements. Granted, substance is critical. No matter how good the soft skills are or how convincing the leaders are, if the content isn’t solid then nobody will follow. But what is more surprising to many teams is that even the most elegant and perfect deliverables often don’t have impact. Why? – Because the team hasn’t positioned the larger workforce to embrace enterprise architecture content and to use it in their day to day work.

Improving the EA team’s style is often where we spend time with clients, specifically working on the “art” of practicing EA. Though many EA’s wish there was a methodological approach to these softer elements, there really isn’t one that works in all cases. People, perspectives, culture, and individual skills vary widely from organization to organization. One approach is to look to lessons learned from the organizational change management discipline, particularly as they apply to driving change across and down into an organization. There are tried and true techniques for preparing organizations for change, conducting education and awareness campaigns, gaining support and participation, and communicating effectively through a variety of different channels. After all, one of the valuable outcomes from EA is helping an organization move from an emphasis on tactical execution and silo behaviors to one that includes a larger, enterprise-wide strategic element. Substance is great, but style really does matter.

1. Enterprise Architecture defines the changes necessary to support strategic direction in 5 core areas:  Business activities, business information, application portfolio, data, and IT infrastructure.  The first two are the realm of Business Architecture, while the final three are the responsibility of ITA architecture, although this is for purely semantic and separation of responsibility purposes.  BA and ITA changes are related and should be coordinated accordingly.
2. Organizational Change Management is the process for altering other aspects of the enterprise that leadership need changed, such as the organization’s structure, resources, capabilities and behaviors.  These changes are necessary to enable and leverage the coming changes of the Enterprise Architecture.  This includes training for new skills, using new systems and information capabilities, identification of obsolete and new roles within the workforce, understanding the impact on the reporting structure of the enterprise, and introduction of new technology capabilities to the affected workforce.
3. Organizational Change Management, like EA, is not intended to concentrate on change within the IT environment, but rather holistic, enterprise wide change and the accompanying implications within a complex ecosystem.

In general, we believe that aspects of organizational change management happen as a byproduct of some implementation efforts, such as training for a new system, or part of a strategic planning effort, or even some mature HR programs.   But there seems to be a lack of systemic, coordinated organizational change management that is related to a corresponding EA program, introducing significant change into an enterprise.   We are not suggesting that EA teams take on additional responsibility, but like other necessary disciplines that have accompanied EA as a part of an enterprise’s significant transformation – governance, portfolio management, service management, and value management to name a few – EA teams can articulate and demonstrate the need for a professional approach to organizational change management.

Every EA team I work with these days is overloaded. I believe that much of the time spent worrying about structure and organization is time better spent elsewhere. Yes, I know that there are just some HR issues that must be addressed, team members need job descriptions and performance plans, and frankly most people won’t even join a team unless they have a reasonable understanding of their responsibilities and how performance will be recognized.

Beyond that, though, I find that many leaders find themselves slicing and dicing roles too finely and creating a lot of unnecessary work for themselves. In fact, doing so often works against the team and inhibits their ability to be effective. The team becomes just a container for a collection of individual contributors, basically working alone and rarely interacting. The very essence of EA is that everything, in some way or another, depends on everything else. The more you separate coverage areas, the more difficult it is to stitch it all together.

Basically, I am saying to not sweat the organizational issues any more than you must to get a few strong players onto your core team. Don’t be too concerned about segmenting responsibilities discretely among domains. Let individual assignments adapt to the content needs of the enterprise and allow your core group to float among them, learning, growing, and sharing perspectives. Encourage everyone to work together as a team and dynamically rotate individual leadership and deliverable assignments. The team will be better off and the members will be as well, plus less time will be spent deciding who does (and doesn’t) do what and more time will be spent on results.

There are a number of differences (amount of available resources, degree of complexity, flatness of the organization structure, number of elements in the application portfolio, etc.) that affect the approach, effectiveness, readiness and deliverables of EA.  But one that I think is one of the more complex to deal with and has the biggest impact on the effectiveness of, is the level of federation vs. centralization of EA.

In a smaller organization, there is much more of a tendency to standardize as much as possible due to the lack of resources for specialized technologies and skills and the propensity to outsource as much as possible, especially now with the progress of the cloud.  In larger organizations, there is usually a lot more inertia behind standardizing the infrastructure beyond the desktop, outsourced or not, while a lot of pressure from business users to have uniqueness at the desktop and within the application and data portfolios.  While this pressure exists from individual users or departments, there seems to be a lot more understanding within the business leadership that complexity and costs are getting out of control without more standardization of systems and data.  So the question becomes “What do we standardize and what do we federate?”

Three keys to being successful with federation decisions:

1. Understand your business’ operating model.  As discussed in a previous entry, the operating model concept from “Enterprise Architecture as Strategy” is a guide to the level of business process standardization (application standardization) and business process integration (data standardization) that the business requires.
2. Develop a capability map or taxonomy for your systems to identify the overlaps that exist within your application portfolio.  These capabilities tend to be a mix of functional (business) and technology capabilities that are delivered by automated solutions.  Using a simple matrix to relate your applications to the capabilities delivered by that application tends to be very revealing of the potential candidates for reducing redundancy.  However, capabilities are defined at a higher level than individual systems user requirements, to there is still going to be some compromising that is necessary when eliminating/replacing duplicate applications.
3. Don’t go overboard.  Not everything that could be standardized needs to be standardized.  Identify the areas that will have the biggest impact, whether that be cost savings or increased functionality or good will, and prioritize standardization efforts accordingly.

As you develop a better idea of what areas to standardize, you can begin institutionalizing your foundational architecture within the infrastructure, operations and development groups.  This will result in professionals in these areas spending a majority of their time on areas that are unique, and quite likely contribute to the competitive advantage of your business.