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.

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.

Top-Performing EA Teams – A Panel Discussion

I had the opportunity last week to moderate two panels at the Troux Worldwide Conference. The first panel included EAdirections’ Tim Westbrock along with Mike Walker from Microsoft, Aleks Buterman from SenseAgility and Paul Preiss from IASA. The theme of the panel was a general discussion on characteristics of top-performing EA Teams. To begin the conversation, I asked each panelist to describe what a top-performing EA team meant to them. What I had originally believed to be a softball question that would show the breadth of issues and perspectives on EA turned out to be more controversial than I had expected.

The panel became caught up in the role of EA and the role of IT architects. Unfortunately, the conversations became focused on the differences in the roles instead of how they work together, diving too far into a differentiation of the “primary” roles and skills of each. It revealed some of the confusion around EA and shone a light on many of the issues that practicing enterprise architects must deal with on a daily basis. What I had hoped would be a conversation addressing how the EA function must be multi-purposed, strategic and tactical, business and IT-oriented, and with an eye to both short and long-term value delivery became overly focused on narrower perspectives. We had a few rough spots as we worked our way through the session, but luckily we ended well. We landed at the recognition that while the roles are different they share some common skills and, after all, they should be collectively working to achieve positive results for their organizations. Individuals in both of these roles will inevitably be working closely with each other.

Personally, I believe that the biggest part of being a top-performing EA team is learning to strike the right balance across the perspectives listed above. It isn’t about doing just one thing or having a “primary” concern as much as it is about how well the EA leaders cover the bases, shifting emphasis from strategic, business-oriented concerns, to helping certain initiatives head down the right path, and then back again as dictated by the situation. It is about breadth, and reach, and longevity.

In future posts Tim or I will examine several of the questions asked by the audience, some answered by the panel and others that we didn’t have time to address.

Highlights of IASA World Summit 2010 from EAdirections

The IASA World Summit was another interesting event from Paul Preiss and his crew. Seems like the speakers get more interesting and relevant to EA practitioners at each IASA event. The ongoing debate on “Is EA a profession, a role, a specialty or something else entirely?” continued in full force.

Scott Ambler, IBM’s Chief Methodologist for Agile and Lean, spoke of his impressions of the roles and responsibilities of architects in an Agile environment. As always, when listening to Scott, I learned a lot and agreed with most of what he had to say. Since Agile is a development approach, most of what he talked about was pertinent to software architects, solution architects, project architects and application architects, but not enterprise architects. Not to speak for Scott, but I believe that is a distinction that he did not make, but would agree with. Scott?

George and I participated in a lively panel discussion with Scott Ambler, Paul Preiss, and Alan Hakimi, a senior architect in Microsoft’s Cloud Architecture group. A special thanks to Andy Ruth, who quite ably moderated our panel with a great set of questions and a little bit of an edge. We had a great discussion on topics like CEO elevator speech, best traits of an architect, the value of an architect spending time in the trenches, metrics for architecture, and a variety of other topics that the audience seemed very interested in hearing about.

We concluded our participation with a presentation on the roles and responsibilities of various architects across the different levels of enterprise architecture, including a discussion on our position on the separation of business architecture from IT architecture. The presentation was received very well. For a link to the whole presentation, see my post entitled “Architect Roles and Relationship with EA.”

An interesting, although not unexpected, bunch of side comments and discussions throughout the event held a common theme – the impact of cloud computing on EA, IT and business models.  George and I will be sharing more of our thoughts on this over-hyped, but definitely relevant theme over the next few months.

EA and SOA Revisited

There has been a lot of discussion recently on online forums, phone calls and visits with clients and prospects, and in the analyst community about the relationship between enterprise architecture and service-oriented architecture … again.

Three years ago EAdirections did a webinar with David Linthicum entitled “When EA and SOA Worlds Collide.”  (Both the presentation and webinar recording are available.)  I was recently asked to revisit that presentation with a client for one of their internal meetings as they just got internal approval to implement an ESB as part of their SOA strategy.  Based on the recent activity, both within and outside my own conversations, it seems that not a lot has changed in these three years. 

We have always positioned SOA as one of the modes of architecture and development that an EA should include, but it is not the entirety of EA.  You are still going to have batch feeds and other non-service-oriented modes of systems integration and development.  While there has been an increase in the implementation of SOA and the maturity of EA functions, it seems as though the main disconnect that we pointed out in our webinar still exists – Multiple SOA projects going on without being part of an enterprise SOA plan.  There are a variety of different reasons for this, but to me, it boils down to the lack of an answer to 2 fundamental questions from a holistic perspective:  What services should we build?  Who will use them?

In order to answer this question, the scope of analysis must be not only beyond the project level, but beyond the IT perspective.  Enterprises need to have a better idea of how they are going to operate, where the opportunities for redundant service delivery are, and where integration should be implemented among its current and future business processes.  Business architecture is the key to figuring out the answers to these questions.

So I guess I misspoke (typed) earlier when I said nothing has changed.  There has been one very big change in the three years since we did that webinar – business architecture has left the realm of possibility and potential and is positioned to actually help some organizations be more successful with SOA, as well as other modes of architecture within the overall EA.

Transformational View of EA

OK, so you think you are practicing Enterprise Architecture, right? As I have pointed out before, the key is the answer to the question, “Are you architecting the enterprise, or are you architecting IT?”

As I dare say, most of you (if not all) would answer honestly that you are architecting the IT environment (apps, data and infrastructure), albeit with a significant alignment with the business of your enterprise. In any case, as I have been having this conversation with audiences, practitioners and clients over the last couple years (or even longer as a client of mine pointed out yesterday – Thanks, Marc!), I have been suggesting that true EA requires business-owned Enterprise Business Architecture (EBA) and Enterprise Information Architecture (EIA).

The implication of this suggestion is that the EBA thought of in the traditional sense is not within the domain of IT; but rather owned, driven and primarily developed and maintained by a group of business professionals within the enterprise. Further, there is also a separation of EIA and Enterprise Data Architecture, with the former under business direction and the latter under IT direction, joining EA efforts for application and technology. Figure 1 depicts the relationships described above.

There is a role for IT EA professionals to play. As the figure suggests, a relationship exists between the business domain and IT domain. Initially, the IT architects must translate the impact of the business and information domain upon the architectures within the IT domain. This is done primarily through modeling and capabilities analysis, a topic for another time. IT professionals have the modeling experience, plus a vested interest in the outcome of the business and information architecture efforts, to be valuable members of the team working on the business domain architectures.

Recently, I have been working with an organization going through a significant transformation and they decided to do exactly what I have been suggesting. A group of business representatives including IT representation, lead by a representative of the executive leadership team, has taken ownership of business and information architecture to define how the business will transform. It will then become the IT Chief Architects responsibility to lay that business blueprint on the IT landscape to translate the changes necessary within IT to support the business transformation.

Let’s hope this is the beginning of a trend.

Webcast on Business Architecture

We have made our position pretty clear on this topic, but  just to make sure everyone caught it - We think that 2010 marks the year that Enterprise Business Architecture has finally become a legitimate concern for a singnificant number of organizations, probably more than a quarter of organizations practicing EA. 

To further clarify some of our thoughts, George and I sat down and recorded this webinar. 

EAdirections On Business Architecture

View more videos from Tim Westbrock.

Let us know what you think.

My Take on the Q&A from the The Open Group Seattle Event …

I recently attended The Open Group Architecture Practitioner’s conference in Seattle.  During the event, I was given the opportunity to present a Keynote on the Language of Business Architecture, which I thoroughly enjoyed.  A couple of my peers, Mike Rollings of Burton and Henry Peyret of Forrester, were present and gave interesting presentations, as well as participated in a panel discussion, with Business Architecture themes.  There were several questions posed during the panel and Q&A sessions following their presentations upon which, surprisingly, I also had an opinion.  With apologies to Mike and Henry, I thought I would share some of them with our readers.   And George has an opinion or two, as well.

Q1:  If Enterprise Architecture as practiced by most is really IT Architecture and Enterprise Architecture is not a term that will be embraced outside the IT organization, what should we call it?

Tim’s Answer:  Although it is not as catchy, my first thought was Enterprise Planning & Optimization.  Until something sexier or more appealing comes along, this is my suggestion. 

George’s Answer: I can live with that and have never found anything better.  Several years ago, at successive Enterprise Architectures Conferences (EACs) I ran working group sessions to “rename” EA.  Each time, the group concluded that ”even with all the undesirable connotations of the name ‘EA’, we can’t come up with a better name”. 

Q2:  Have you ever seen EA report outside of IT?

Tim’s Answer:  To this point, I have not worked with a company that has the EA function reporting outside of EA permanently; however, I have worked with companies where the head of EA has had occasional assignments working for a corporate executive (not line-of-business) on strategic initiatives. 

George’s Answer: I have seen a few forward-looking organizations exhibit EA-like behaviors with notions like future state, enterprise principles, enterprise operating models (a la “EA as Strategy” – Ross, Weill, Robertson) as context, etc., usually within the enterprise strategic planning function.  They never call it EA, though.

Q3:  Do you see many EA groups with defined qualitative metrics?  What are they?

Tim’s Answer:  Most EA groups need to have some kind of metrics or KPIs in place, and as most of the benefits of EA are indirectly realized through the efforts of others (project teams, operations, procurement, etc.), they tend to be qualitative.  I have seen clients measure reductions in complexity and asset portfolio mix that have both qualitative and quantitative elements to them.  Perhaps the most common qualitative metric I see is a periodic assessment of EA maturity/effectiveness.  Organizations compare the ratings in different categories from one year to the next to see where they are improving and where they are lagging.

George’s Answer: I agree with Tim and would add that, occasionally, I see many organizations implement specific quantitative measurements because their HR systems require them to have something designed to evaluate individual and/or group performance.   These tend to be behavioral measures, not value measures.  Examples include completion of specific EA deliverables, or reducing the number of EA exceptions requested by projects.  The latter is achieved by creating appropriate reuseable patterns that have high utility across the enterprise, solving specific implementation scenarios in a repeatable way, through education and project coaching, etc.  The leadership team must believe that these behaviors will eventually drive desired outcomes in the company if the architect is to have any chance of representing these as legitimate metrics.  

Q4: In large organizations, line-of-business (LOB) architectures abound.  Is this an inhibitor or opportunity?

Tim’s Answer:  I think that it can be both.  If you do not create a unified, but federated, EA practice across the organization, then you run the risk that the LOB architectures are inconsistent, increasing cost and complexity overall.  Also, the LOB EA groups will tend to be more customer-focused, giving the LOB what they want, which makes it more difficult for Enterprise-level architecture decisions that are optimal company-wide, to be embraced at the LOB level.  This federated approach is what we see at most large complex organizations, so it must be turned into an opportunity to be successful.  Without leveraging the extended architecture community, the EA will probably be largely unsuccessful in large organizations.

George’s Answer: It could be both, but being a cup half-full person, I usually see it as an opportunity.  If even a small part of a large organization can do EA successfully, that’s good for them.  With luck, it will spread and grow to others.  If there are multiple LOB EA’ish functions, perhaps they will be able to identify opportunities for commonality and leverage, but only if that really makes sense for that particular company.  If critical mass or commonality never materializes at the big-”E” enterprise level then at least part of the company has embraced EA concepts.

Q5:  How do you define a business capability?

Tim’s Answer:  To me, business capabilities are the next layer of abstraction below business strategies and objectives,   defined as the capabilities that the business operations must deliver to achieve those strategies and objectives.  Since capabilities are usually defined at a higher level than requirements, there is more opportunity to find capabilities that cross organizational and functional boundaries.  This approach helps identify the areas to which we can architect, rather than getting right to the solution. 

George’s Answer: This is a tough one because everyone has their own interpretation.  The simplest one I have seen defines a capability as “the ability for an organization to perform a particular piece of work”.   I like it BECAUSE of its simplicity.  Of course, then one must be able to define “work”.   One example capability might be, in a product company, packaging and communicating product features to potential customers.  That capability manifests in the marketing function.

Q6:  Do you think the long-term future of EA is to merge or disappear?

Tim’s answer:  I think for the vast majority, the answer is neither.  Ultimately, EA is all about leadership – providing it and being recognized by it.  It seems to me that the leadership of most organizations is interested in surviving, keeping the status quo, and being tremendously risk averse.  In those kinds of circumstances, I see EA following the enterprise leadership and basically staying the same.  Those organizations that truly embrace EA’s transformational capabilities and allow it to reach its potential may end up creating a hybrid version of EA – one part that continues the traditional IT architecture leadership under the CIO called EA, and one part that merges into the executive offices to provide leadership in planning and strategy, called something other that EA, perhaps Business Architecture (but I kind of doubt it).  In these cases, there will be a strong relationship and integration between EA and BA. 

George’s answer: I have long maintained and continue to be of the opinion that a well-run EA program “melds into” and becomes part of the management and decision-making fabric of the enterprise.  It isn’t EA itself that we ultimately care about – it is just the name we are stuck with to represent a future-oriented, holistic, business driven, enterprise-wide context that informs decision-making.   What we really care about is the installation of those EA-like concepts, behaviors and an enterprise context into how the enterprise works – whether it is called EA or not.   By the way, I think we are a long way from this happening for anything more than a relatively small fraction of organizations.

Let us know what you think.

Hold the Date! – George Paras Keynote at Denver IASA ITARC on May 6, 2010

In a keynote presentation at the upcoming IASA ITARC Denver Event I will be discussing  the leadership challenges that many current and aspiring IT leaders face in their organizations, and how they can overcome those challenges by applying selected enterprise architecture concepts to their decision-making framework.  Not surprisingly, I advocate moving EA “upstream” within the management structure and expanding the context to make it more relevant to the business.   Doing so isn’t easy.  It requires a combination of skills in leadership, process integration within the Office of the CIO, and appropriate content in business and information architecture.   In this session attendees will learn how to get started on this journey.  

If you are in Denver and plan to attend, please let us know.  We’ll be available to discuss  ideas with any organization interested in expanding the scope and reach of their EA practice into business-oriented EA. 

The International Association of Software Architects (IASA) is the premier association focused on the architecture profession through the advancement of best practices and education while delivering programs and services to IT architects of all levels around the world.  The IT Architect Regional Conference is the first event in Minnesota to address the pressing needs of IT architects today. There are 12 seminars and two tracks separated by specialty: Enterprise and Fundamentals. Architects of all levels can take their skills to the next level.

Don’t Call It EA if It Isn’t EA! – Atlanta ITARC Event

Most organizations that claim to have an “enterprise” architecture practice are really only doing “IT” architecture (ITA).    What leads us to say that?  Our research shows that most organizations have limited their scope to include only IT elements like infrastructure, data and applications.  That’s OK in and of itself and it is a step up for many organizations, but that’s not EA.  Most  definitions of EA define it as creating a business strategy driven future state for the enterprise.   To achieve that goal, EA must include Business Architecture. 

In a keynote presentation at the upcoming IASA ITARC Atlanta Event titled “Don’t Call It EA if It Isn’t EA!: Moving from IT Architecture to Enterprise Architecture”, Tim and I will continue the discussion he began in his blog entry last year, one of our most read and most commented entries.   We plan to explain the rationale behind this statement and share a few tips with attendees on steps they can take to move to a more fully realized EA practice.

If you are in Atlanta and plan to attend, please let us know.  We’ll be available to discuss  ideas with any organization interested in moving into business-oriented EA. 

The International Association of Software Architects (IASA) is the premier association focused on the architecture profession through the advancement of best practices and education while delivering programs and services to IT architects of all levels around the world.  The IT Architect Regional Conference is the first event in Minnesota to address the pressing needs of IT architects today. There are 12 seminars and two tracks separated by specialty: Enterprise and Fundamentals. Architects of all levels can take their skills to the next level.