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.

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?

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?”

Characteristics of Effective EA

There are a few characteristics of an effective Enterprise Architecture (as well as IT Architecture) practice and its artifacts that must be established and maintained throughout its existence.  In order to be effective, EA and ITA need to influence investment decision-making at the portfolio level.  This means being able to show the impact of investment alternatives across the enterprise, on other investment choices (including current investments) and over a longer period of time than just the current and next budget cycle.  Regardless of goals, objectives, industry, size, or stage of maturity, these 5 characteristics are necessary for effective EA and ITA to influence the investment portfolio:

• Business Driven
• Forward Looking
• Enterprise Breadth
• Maintains Linkages
• Proactive

Business Driven:  In order to be business driven, the EA program needs to involve professionals with an understanding of the operations and the executive leadership of the organization.  If you are architecting an enterprise, then your primary audience is the group of individuals with overall responsibility for the enterprise as a whole.  Your artifacts need to be able to communicate at the executive level, as well as create a forum for collaboration on the impact of strategy on the operations of the organization.   HL context models, relationship maps  and strategic capability change analysis are the deliverables that represent this characteristic.

Forward Looking:  Too many EA programs attempt first to impact implementation level decisions and projects.  While this is not only futile (one an effort is at the implementation level, EA impact is minimal at best), but also potentially dangerous.  Without an idea of the long-term direction of the business processes, information assets, business systems and technology, what meaningful and systemic guidance can EA or ITA provide at the implementation level, or even at the design level.  The architecture as a whole must be based on a consistent and portfolio-oriented view of how the enterprise will evolve as a whole over time.  This only comes from looking 3-5 (or more in some instances) years ahead.  Roadmaps are the deliverables that represent this characteristic.

Enterprise Breadth:  Many organizations have a history, sometimes successful even, of silo-oriented decision-making.  However, as complexity has increased and rates of change have decreased, the impact of silo decisions is being felt by these organizations.  And it is usually not a good feeling.  To combat this, EA must have an enterprise-wide scope to help senior executives understand the impact of decisions in one silo on other parts of the organization, because within the silo, this is not easily recognized.  And for the most part, if this perspective is not maintained by the EA group, it may not be evident anywhere.  This characteristic should be represented in all types of EA deliverables, providing the context to link artifacts from other levels of architecture (domain, solution, etc.), as well as planning  and development activities.

Maintains Linkages:  To increase the impact that the previous characteristics can have on overall effectiveness, the EA must establish and maintain both vertical and horizontal linkages in the participation and deliverables of the program.  EA is not responsible for the creation of every planning, design and modeling artifact in the enterprise.  But to increase the value of the lower level artifacts, as well as enable the impact of business driven, forward-looking, enterprise wide activities and deliverables; linkages across silos and domains and between levels of architecture must be established and maintained.  These linkages are generally represented in the overall EA meta model.

Proactive:  As I mentioned earlier, many architecture activities are focused on implementation and project level details, which is too late in the life-cycle to have meaningful impact without the benefit of process and artifacts that reflect the above characteristics.  Please don’t misunderstand my message.  EA needs to be able to impact the implementation and project level decisions, but not in the reactive way we see it happening in many organizations.  By creating teams, process and artifacts that are business driven, forward-looking, enterprise wide and maintaining linkages; EA can proactively impact the mix of projects and the implementation level design, technology choices and integration BEFORE projects are even started or implementation decisions are made. 

The true test of EA effectiveness is the ability to change implementation level decisions based on a reflection of what is in the best interest of the whole enterprise.  Without these 5 characteristics present, an EA program will struggle with that test.

Improving EA Team Performance

With the arrival of the New Year, many EA teams are in the final stages of setting their annual objectives.  This year, we find that many are being asked to perform at a level significantly higher than last year.   They must do so in response to higher expectations placed on them by leaders who believe that EA plays a critical role in moving the enterprise into the future.  

Many annual objectives documents are primarly structured as lists of projects  and deliverables that the team must complete in the next planning period.   While hard deliverables are necessary and expected, every EA leader should also consider adding objectives designed to improve team performance and to address “how” the team is going to accomplish their assignments.   Why?  Because EA success requires predictable and consistent performance by the team as a whole and by its individual members.

One of the most interesting observations from studies of EA team performance is that the typical team profile of a collection of highly skilled and specialized individual contributors isn’t necessarily optimal.  To be successful, teams populated that way must learn to function as a team, supplementing the natural tendency for individuals to work alone.  Enterprise architecture is inherently cross-domain in scope.  Only by working in collaboration across domain specialites will the team be able to quickly address the many dependencies that are part of the modern enterprise.   

We recommend that EA leaders employ the following techniques when striving to improve their overall team performance:   

Develop a common language: Words and concepts are important.  Adopt/adapt a “language of EA” that makes sense for your organization.  A common grounding in EA core concepts can go a long way to unifying a team.  Look to the more widely used and common industry approaches to EA, take a class, or ask us.  We’re happy to make recommendations on practical approaches that will work, and show you how to adapt them to your needs.

Be a Team: Get together frequently, in person and/or virtually.  Eschew “project status reporting” meetings in favor of strategic discussions, cross-domain issues resolution, trend analysis and healthy debate.

Collaborate and Communicate: Actively recruit and engage external parties and bring them into the discussion.  Learn to exploit “social media” style connections to engage with these larger audiences. 

Learn to Lead: EA is a “lead through influence” discipline.  Take a leadership course, but be careful to select one focused on “soft” leadership styles.  It isn’t about traditional personnel management techniques.

With people as the critical element to EA success; it only makes sense to invest in team skills and performance.   Unfortunately, many teams put disproportionate emphasis on templates, frameworks and deliverables.  Make it a practice to visit/revisit the health and productivity of the team.  Don’t wait until next January to start.

EA Activity Catalog

If an enterprise architecture team tries to be everything to everybody, at all possible levels of detail, at every point in time, it will fail.  The result will be that it doesn’t do anything for anybody, which would be unfortunate.  When it works, EA can have a significant impact on the quality, consistency, and speed of decision-making.

How can you avoid the inevitable overload and the misunderstood expectations?  Every great enterprise architecture team I know constantly examines the work it is doing in the context of the resources it has available, the number of hours available each day, the objectives it must meet and the expectations of its stakeholders.  In addition, the leaders appreciate that EA teams evolve over time and adjust to the changing needs of their business.  The key is to know which activities they must perform, how many at a time, how frequently and in what order.  The attached presentation is a starting point to understand the range of activities you COULD do.  The challenge is to determine which of these you CAN and SHOULD do.

Common Denominator: Business First!

I am working with a couple different clients now on their approach to enterprise architecture, and not surprisingly, their approaches are vastly different.

One company has a core group of EA’s, working primarily on what they have named Business Driven Target Architecture, which is a bit of a mix of business, application and data architecture.  The scope of these ranges from very project-specific to business-unit wide.  In addition to this work, they have other efforts underway to cross-reference their primary work with each other, company and division strategies and trends in business and technology.  While their primary work is very solutions oriented, their secondary work is enterprise-wide and will, over time, provide more enterprise views of the business and application landscapes.  There is another group that is focused on the technology architecture. 

The second client also has two groups working on EA. The first group has been in existence for a few years and is an internal IT group, headed by the full-time Chief Architect, with several architects acting in a part-time EA/part-time solutions architect capacity.  The Chief Architect leads the IT architecture effort with internal IT resources , but also is a member of the second group.  The second group is composed of a variety of business and IT representatives, with a focus on business architecture and strategy.  Without the second group, the internal IT group has struggled  to gain the traction necessary for EA to be more effective.  The second group is just getting started, but they are already beginning to see more support, especially given the stature of business architecture group’s members and the vocal support of the company’s chief executive.

While these two companies are approaching EA very differently, they both have one very important characteristic in common: They both have a “Business First” approach.  The first company starts their Business Driven Target Architectures (notice the First word in the name of their approach) with an understanding of the business goals and strategies, pain points, processes and business capability changes.  That is what separates it from a straightforward solutions architecture approach, in addition to the cross-referencing to their secondary work.

The first company, after struggling with traction, also decided there needed to be more of a business first sense to their efforts.  So they not only created a Business Architecture Team (there is that word first again), but they also focused the group on defining a holistic business operating model as the context for many of the business process integration and business process standardization (see my earlier post that describes their approach) recommendations.

Both of these companies will continue to modify their EA approach as necessary, but one thing will remain constant: Business First!

Architecture Readiness? What is that?

Recently I saw a question posted on a popular EA forum, asking about detecting the “architecture readiness” of the poster’s organization.   That got me to thinking about what we mean about “readiness” and is it that relevant anymore.  I admit that in the mid-90′s we would discuss the notion of an organizations readiness to embrace EA, but my perspective has changed drastically.  I think that the question is no longer “Is my organization ready to embrace and support EA?” but rather “How can I be effective in utilizing an EA approach in my organization?”  Clearly, the issues demanding EA support are still prevalent and the maturity of EA as a discipline has increased during the time since the mid-90′s. 

I do not believe that any EA function can be diagnosed quickly, as most of the issues regarding “readiness” are probably a unique combination within a company.  It starts with identifying the leverageable strengths, obstacles to overcome, and methods of mitigating those obstacles – including awareness at the executive level.  I don’t believe that any organization is completely “unready” for EA, but there are certain factors that are a quick read into how long it will take for EA to be a valuable, recognized formal method of helping the organization plan, rather than just a glorified design standards group.  Key among those factors is the understanding of and desire for EA as a strategic planning discipline by the CIO first, and the rest of EA management, second.  Many times, it helps to build some of the context level artifacts BEFORE you attempt to build executive awareness as those artifacts can be a very powerful part of the argument.  There are other activities (communication, collaboration, process integration, separating and defining roles and responsibilities among different architecture levels, and governance to name the most important) that all work together to establish a culture of EA – which is really what we are talking about here.

Portfolio Management Still a Key to Realizing EA & IT Benefits

Enterprise Architecture as long been considered a planning discipline.  Many times when asked about the value of EA, people will comment with the old axiom, “What is the value of a plan?”  While there is certainly some inherent value in the artifacts, processes, and relationships developed by EA in and of themselves, the real benefits are achieved through the implementation of EA plans.  However, a conflict has always existed between the EA representation of a long-term enterprise view and the near-term bounded perspective of implementation projects.

For many years, well over a decade, we have been helping organizations overcome this conflict by developing a portfolio perspective of the many (sometimes hundreds or thousands) of implementation projects underway, approved and being considered.  While more organizations are attempting to maintain a portfolio perspective, there is still a decidedly immature approach to making portfolio decisions (managing the portfolio) from an enterprise perspective.

There are a variety of reasons for this:

• Complexity / Volume of the project portfolio
• Lack of tools in use to help organize / analyze the project portfolio
• Lack of business participation / Perception that the project portfolio is an IT organization/CIO’s responsibility

The good news is that these problems can be overcome.  For instance, not every single unit of work defined as a project has to be accounted for in the portfolio.  Most successful portfolio management efforts include the creation of criteria for inclusing into portfolio analysis.  These factors can range from duration, budgeted expense, capital expense, and resource allocation to strategic impact, level of risk, ROI, and number of depencies. 

As organizations continue to mature their approach to portfolio management, they quickly find out that it is not all about realizing benefits from EA.  It is about making vastly better investment decisions for the enterprise.  The EA deals with the future vision of the enterprise.  The project portfolio management process, if done well with the input of EA, will provide a balance to fulfilling the immediate needs of the enterprise while also advancing the strategic vision of the business.