Tim Westbrock to Speak at IT Leadership Forum, Dec. 13, in Atlanta

Join Tim at the IT Leadership Forum, Dec. 13, in Atlanta, sponsored by alfabet.

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!

Too Much Tactical Focus with Business Architecture?

As more and more organizations embrace Enterprise Architecture with a concerted effort in Business Architecture (BA),. we are beginning to see one of the common pitfalls of IT Architecture (ITA) spill over — too much focus on the tactical, project level.  Apparently, getting business representatives involved in applying EA discipline to the business architecture does not mean that the effort will remain high level, strategic and forward thinking.  Just like many ITA efforts, BA efforts result in the identification of work that needs to be done to support the enterprise’s transformation.  And also like many ITA efforts, once the resulting work is started, many of the BA participants find themselves involved in the transformation effort.  Another factor that needs to be considered is the lack of dedicated BA resources, such as a Chief Architect or Business Architect or BA team.  The BA efforts are usually staffed entirely by a virtual team, all of whom have real, demanding full-time jobs.

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.

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.

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.

EA Principles Have Little Value

Just recently I learned that a client’s CIO leadership team began a detailed and substantive discussion on EA principles, the implications they carry for their organization, and how they can use them to transform their journey into the future.   I don’t see this as often as I’d like.  While gaining that level of leadership engagement in the creation and use of EA principles has long been a desired outcome, it is still somewhat rare.  In this case, it was a combination of good luck, good timing, and a skilled Chief Architect who was able to keep principles visible and to broker the discussion with leadership.  There is a lesson to be learned here.

With common sense as a significant part of a good set of EA principles, it is easy for a leadership team to write them off as “a statement of the obvious” and not pay much attention.  As enterprise architects, our goal must be to make principles relevant.  The approach is for us to demonstrate how they are used in practice and to show that they are more than a collection of catchy phrases.

For each principle individually, and for the set as a whole, it is important to be able to explain them in real-world terms.  This means choosing principles that guide desired behaviors and explain their rationale and implications in a form that leaders can relate to, with an emphasis on how they affect decision-making at all levels.

Unfortunately, I see many examples of principles that don’t gain traction.   When that happens, EA principles have little value.   When I diagnose the situation I often see that a lot of energy was consumed in creating the perfect written words, with less energy committed to bringing the principles to life.

A few tips:  Always be sure to include rationale and implications, but don’t worry so much about making them perfect, just strive to make them good enough.  Invest the extra energy in bringing them to life in four ways:

1. Ensure that ALL members of the core and extended EA teams understand what the principles really mean and how they are used
2. Be sure to actively and visibly reference the principles in the process of creating future state EA content
3. Refer to the principles and use them as a test in ALL solution architecture and coaching work
4. Carry the principles with you in discussions with leadership at every opportunity

By using the principles every day, their value will eventually be self-evident and leadership teams will recognize them as a helpful tool in their management arsenal.

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.

Did We Forget about Adaptive EA?

Lately, I have been wondering in my dealings with clients, prospects and online forums if we have forgotten this most basic, but important goal of EA – adaptability – the ability to accommodate change quickly and easily.  Complexity and the rate of change continue to increase, but the focus of many EA groups seems to be more focused on accommodating particular focus areas – major projects or business areas.  While much of this is because we are in a more tactical arc of the pendulum swing right now due to the economy and resource constraints, it is important to maintain a focus on enabling change while we work on specific domains or initiatives at the sub-enterprise level. 

There are two elements that are crucial to an organization creating and maintaining an adaptive environment – standards and governance.  Standards provide a common place to start – whether they be infrastructure standards like standard vendors and products for hardware and middleware; or application standards like coding standards, common integration practices or reusable components; or data standards like common metadata, naming standards and authoritative sources.  But in addition to defining these standards, effective governance must be in place to ensure that the standards are applied, especially in times such as these where there is immense pressure on project teams to deliver value and results as quickly as possible.  It is actually times like these that demand EA and governance to be most effective – when there seems to be an organizational push to eliminate anything that might delay project delivery.  This is when EA, IT and enterprise leadership must continue to place adaptability as a primary goal for planning, design and implementation.

I have some other ideas on this area as well, so see my other post this month for more.

Is EIA the Key?

As organizations continue to struggle with the complexity and amount of change to deal with, the EA team plays a crucial role in laying a foundation of adaptability for the organization to build from.  Once an organizations has done an acceptable job of providing a standardized infrastructure and at least basic governance of infrastructure standards, focus tends to shift towards the application portfolio and integration approaches.  This is natural and seems to conform to most of the evolutionary models of EA, such as the one from MIT Sloane CISR in Enterprise Architecture as Strategy.  However, I would like to provide you with an alternative to consider as I see organizations continually struggle with business units demanding more uniqueness to the functional systems they need to run their part of the business.

I think the key for some organizations to achieve a more adaptive environment is to focus on architecting the information and integration environments.  If information was more standard and consistent BETWEEN information systems with a common integration architecture (standard methods, components, messages, and middleware), then the information systems themselves could be unique functionally.  The architecture would need to provide the means of translating information formats and content from systems into the standard format and content for sharing outside the system.  This would also support SOA approaches, cloud computing strategies, mobility, and other approaches being pursued today.

As an EA team, are you focusing on the functionality of a specific area or are you leaving that to the project team, so that you can focus on the shared aspects of an application environment, namely the information assets and integration capability across the enterprise?

Who Decides?

Do you sometimes feel that your EA standards don’t carry any weight? You create them, publish them, and then when it comes time to apply them you find yourself re-justifying the standard or even justifying the need for standards in the first place? Even commonly accepted de facto standards with long histories in an organization can fall prey and need to be re-justified before each use.

It’s a very common story and it points to a fundamental weakness in EA governance. Compliance processes and design reviews alone aren’t the answer – they can often lead to accusations that you are acting like the “EA police”.  An organization needs a robust EA approval process as well.

Most organizations, regardless of maturity and for a variety of reasons, need to address/re-address the question of “who decides?” when it comes to standards, roadmaps and the overall EA strategic direction. The key to success is that some degree of meaningful standards must be decided in advance of the need to actually apply them.  Enterprise Architects, though, SHOULDN’T be the ones to decide (or enforce) standards. Why not, and if not, who should?

Independent EA authority may work for the least controversial EA decisions, but it usually won’t stand up for the big ones or when more powerful or influential leaders choose to go a different way. The root of decision-making authority for EA rests with the body that makes policy and investment decisions for the organization.

Is that practical, or even plausible? It is if implemented in a model that relies on layers of decision-making authority, with delegation pushed downward, while accountability is maintained upward to that ultimate root authority.

We’re gathering data on the level of governance involved in EA standard approval across our readers. Please take a moment to answer the attached polling question, and read more on this topic on our website. We’ll let you know how people respond in a future blog entry.

Common Step to Effectiveness – Alignment across EA Community

A common theme that seems to be coming up often lately with clients, prospects and some of the online forums I read is the gaps and overlaps that exist among the many groups involved in the EA function.  As EA becomes more effective, there tend to be more formalized groups created.  It is common for there to be a central EA team, but also working groups focused on one of more of the traditional domains of EA – business, information/data, application and technology.  

Who creates the standards?  Who decides where standards are needed?  Which teams should be involved in reviewing which projects and investment decisions?  Who models business processes?  These and many more questions will pop up as more and more groups, both formal and informal, get involved in the EA effort.  It is important to define the decision rights authority and areas of responsibility for each group.

Too many times, we see groups let these questions go unanswered and the result is as if EA no longer exists.  Instead of a coordinated, collaborative approach, the enterprise reverts back to several silos of decision makers who think they are contributing to EA.

While it is typical for the Core EA team to have a coordination role; as EA grows, this can become a monumental task as the EA Core Team is usually small and has other areas of responsibility.  So our recommendation is to document the areas of responsibility for each team involved, including non-architecture groups such as application development, infrastructure engineering, database management or IT operations, as well as the decision rights authority for each group as well. 

On a related topic, check out George’s blog entry on Who Decides?