Lack of Enterprise View a Hindrance? Good Solution Architecture is Not Enough

We are consistently being exposed to ENTERPRISE architecture teams without an enterprise perspective in the deliverables and activities in which they are engaged.  Sometimes this is due to a cyclical shift in the priorities between defining enterprise architecture and applying enterprise architecture via solution architecture.  This is a normal, healthy shift that we see happening in maturing EA programs.  However, the occurrence I would like to touch on is when there has NEVER been an enterprise perspective, yet there is an enormous priority placed on solution architecture resources and activities.

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.

EA Tips: Anchor Models

Anchor models are context diagrams that capture the essence of the enterprise as a simple graphic. They should be equally meaningful to both business and IT personnel and should be so intuitive that they don’t require a multi-page text narrative to understand. While we see many models created by EA teams, most are lower level “IT” models of business systems or technology components. Even models that attempt to represent the entire enterprise tend to be IT-oriented. While these models can be very useful, they don’t serve the same purpose as an anchor model.

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.

A Question for Practicing EAs

Why are you doing enterprise architecture?

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?

EA Tips – Style AND Substance

For an EA practice to be effective EA leaders must pay attention to both the “style” of how their team operates and the “substance” of the work they produce. While that guidance isn’t new, in practice I often find that many leaders don’t have the balance quite right. It is worth revisiting as a general EA Tip.

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.

Organizational Change Management for EA? Of Course!

One of the topics, although not new, that seems to be a regular topic of discussion among clients, peers, prospects and vendors is organization change management.  More specifically, how can EA be successful without an accompanying Organizational Change Management program?  Once you get into these discussions; however, the answer to the aforementioned question is “Yes!” but the discussion morphs into what we really mean by Organizational Change Management relative to EA.  Much like the term Enterprise Architecture, I think Organizational Change Management means a lot of different things to different people.  And also like the term Enterprise Architecture, I think there are some things that we can establish a position on to make the effort more meaningful and effective.

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.

EA Tips – Substance OVER Structure

If you read my post on “Style AND Substance” I stated that an EA team shouldn’t spend disproportionate energy on content creation without also paying attention to the many softer, stylistic elements associated with leadership and influence. One without the other and the team will fail. In this “EA Tips” post on “substance vs. structure” I offer that an EA leader should worry only slightly about organization and team structural issues and spend as many cycles as possible jump starting the EA team and getting them to work together to produce meaningful content (strategies, standards, roadmaps, etc.).

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.

Federated EA in Larger vs. Smaller Enterprises

George and I are often asked ”How is EA different between smaller and larger organizations?”

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.

Why No Business with EA?

So there I am sitting on a panel at the Troux Worldwide Conference a couple of weeks ago, answering interesting questions with some interesting co-panelists, when a thought struck me.  “After decades of positioning EA as a discipline for business-IT alignment, why aren’t EA programs more in tune with(driven by, owned by, participation from) the business?”

I’m not just talking about myself positioning EA in this way.  Just about every definition you come across, from vendors, consultants, analysts, and practitioners alike; EA is described as being business driven, strategic in nature, and focused on the long-term future state of the enterprise.  But within most organizations I engage, EA is found to be lacking significant business drivers, business participation or even any level of credibility from business executives.

So I ask again, Why?

I think that there are a variety of reasons for this, and the exact mix of reasons are probably unique for each individual enterprise.  However, I would guess that there are a few factors that are predominant in most organizations.

1. Lack of EA leadership within the IT organization.  I don’t mean that there are no leaders in IT.  I mean that the leadership in IT for EA (let’s face it, most EA organizations are within the IT function) isn’t doing what is necessary to form the relationships and value proposition for EA to be relevant outside EA.  They remain satisfied with a focus on IT outcomes – applications, infrastructure, standards and governance.
2. Lack of business understanding within IT and EA leadership and practitioners.  IT leaders and EA program members must develop an understanding of the core operations, motivational forces, financial model, and strategic plans of the enterprise.
3. Lack of translation of business understanding.  Some EA practitioners have made the initial investment in gaining essential knowledge about the business in which their enterprise competes, as well as the internal operating and financial models, and their strategic drivers.  But the next step is the critical one.  They need to create artifacts that represent that understanding in a way that communicates with senior executive leadership.
4. Too much responsibility at the project/implementation level within IT.  Time and time again, we see very capable EA teams try to gain credibility by helping out as an added resource/technical lead/project manager; only to be given these responsibilities as a permanent part of their charter.

While there are other reasons that warrant consideration (lack of understanding/approval by the CIO, wrong personnel involved, economic downturn); the above represent the factors that demand focused effort to overcome.

What can we do to change this?  Here are a few suggestions:

• Read books and industry literature of a non-technical nature about the industry in which your company competes.
• Experiment with different types of high level models that represent your understanding of your business’ current and potential future state(s).  There are no commonly accepted formats and nomenclature for these types of models, as they are dependent on the executives you are trying to communicate with.  And do not be afraid to have different models to communicate the same thing to different audiences.
• Understand the financial model of your enterprise and how it impacts IT’s value delivery.  You must develop a contact in the CFO office.
• Resist project level responsibilities for your EA team.  If you have to accept them for a short time, develop a plan with your superiors to instill architecture skills into the project delivery staff.

Location, Location, Location – Where Should an EA Team Report?

At the recent Troux Worldwide Conference in Austin I moderated two panels, one on Top Performing EA Teams and the other on EA Leadership. We had many questions submitted by audience members and were unable to answer them all. In the next few weeks Tim and I will be offering our perspectives on some of the questions the panels didn’t have time for and share thoughts on a few they did. “Where should an EA team report?” was one of the latter.

It seems that many EA teams we talk to ask about reporting structure, either as reinforcement that they are in the right place now, or as justification for reorganization if they are not. If I had to answer, without knowledge of an organization’s specific circumstances, I would say something like “given the latest trends in enterprise architecture towards stronger business architecture, the EA Team should ideally report directly to the CEO or executive committee in some form of a strategy function”. This gives the team the imprimatur of executive authority, strong visibility, and broad reach across business and IT concerns – truly the “enterprise” perspective.

But that answer isn’t realistic in most current organizations. First, we’d have to establish that the team is really doing true “Enterprise” architecture vs. IT architecture. A good discussion on what we mean by this is included in Tim’s blog entry from last year on The Transformational View of EA. Transformational EA specifies business architecture that is owned, driven, developed and maintained by business people as opposed to their IT proxies. It is coordinated in partnership with IT architecture-oriented EA’s focusing on the IT and systems-oriented perspectives. Until that happens it is unlikely that an EA Team will reside at the level of my answer above. If it has happened already, they have probably been moved up to that level or are already well on their way.

The question most EA teams should ask would be “What is the best place for EA to report in MY organization and how do I get there?” The first part of that is a much more straight-forward question to answer. For a Team working on IT architecture the best place to report is directly to the CIO as part of an Office of the CIO, along with the PMO, IT Strategy Group (if not already the EA group), and other CIO functions. This positions the EA team organizationally on par with operations/infrastructure, security/compliance, and development/support.

Many EA teams find themselves deeper in an infrastructure group doing technical architecture or as part of development support organization. Is that bad? Not necessarily. It is the starting place for many EA Teams. It’s only bad if the scope and scale of the team’s reach is constrained by it. I have seen cases where the EA team administratively reports into a supportive infrastructure director (or development director) who recognizes the value of EA, their role, and gives them license to practice something closer to holistic, forward-looking, business-driven EA. After all, good EA teams are not self-contained. They are highly dependent on engaging a virtual community of stakeholders and contributors from across the organization. Where the team reports, provided again that the leader is supportive, is less important than what it does and how it reaches out to influence others.

So, the bottom line answer to the question of where an EA team should report cannot be from a purist perspective but instead should be based on a combination of practical realities along with the vision and aspiration of the team to drive value. Whenever I hear the “where SHOULD we report” question I prefer, instead, to deflect it and work with the team to answer the question “how can they drive maximum value”. If they can’t do it where they are then we determine, realistically, “where COULD they report”, and “what will it take to get there?”

Communication Planning for EA

At the Troux Worldwide Conference in Austin 2 weeks ago, several questions were submitted by participants to my panel that we didn’t have time to get to.  Over the next few weeks, George and I will be addressing them.  One that caught my attention was the following:  “What style of communication have you seen be most successful?”

This is actually a topic I have written an article about, summarized below, as it is one of the most common topics that comes up with our clients.

Communication is a key to transforming an enterprise through strategic planning, enterprise architecture, and enterprise portfolio management.  Critical to the success and effectiveness of communication is planning why, how, when, and with whom communication will take place.  The answers to those questions are determined through communication planning.

Effective communication can often happen “off the cuff” or at the “spur of the moment”; however, relying on spontaneous effective communication will not likely sustain most EA efforts.  It is the responsibility of EA leadership to create and maintain a systemic communication plan to support the establishment, execution and effectiveness of the EA program.

Follow this link for the complete article.