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.

Social Networking – What’s good for them is good for EA

Enterprise architects have historically struggled with the process of publishing content to the stakeholders in their organization.  Conventional advice has been to create an intranet site or other document repository primarily serving static documents such as strategy papers, standards lists, domain architecture documents, models, etc.   That approach has its weaknesses, not the least of which is that the content and access methods aren’t particularly engaging to the larger community of casual stakeholders including members of the extended EA community of subject matter experts and contributors, and the more formal members including senior managers and leaders in both IT and the business.

Many organizations have begun to deploy blogs, wikis and other related social networking technologies in response to demand from various user communities for easy to use tools that support collaboration and information sharing.   In fact, many EA practitioners are well down the road choosing social networking technologies and helping the business develop usage guidelines.  

Surprisingly, EA practitioners as a whole have been reluctant to embrace the use of social networking for their own purposes, namely to share their thoughts and ideas with others in the enterprise, and to welcome commentary and perspectives from interested parties outside their own groups.  The key is to become comfortable sharing trends, ideas about the impact of those trends and thoughts on future EA changes, even before fully formed.   Post often and openly, resist the urge to assign rigorous categories, and tag and link freely.

The technology, and the behavioral changes that can result once the team becomes comfortable with it, can help improve the perception of the role of the EA group by the rest of the organization.  It can further recruit additional participants, effectively multiplying the reach of constrained EA resources.

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.

Follow us on Twitter and LinkedIn

EAdirections is now online with Twitter, and we have launched a new group on LinkedIn, the ”EAdirections Forum” .

(Click on the buttons below to follow or join!)

EAdirections

George Paras

Tim Westbrock

Join our Group  “EAdirections Forum” Group

George Paras

Tim Westbrock