By Terry Blevins, Fellow of The Open Group, Enterprise Architect at Enterprise Wise LLC
One of the most frequent set of questions I get are about getting started on an Enterprise Architecture project. How do we begin? What do we need to do first, third, next? My first reaction to this question is usually “please don’t start by asking the client what they want the Enterprise Architecture to do?” I have seen this and it really puts clients off. For a more constructive response, I have directed folk to the TOGAF® ADM and the various guides in The Open Group TOGAF® Library. Though usually thankful, that direction begets something like “thanks for that, but I was just wondering if I can get some practical tips right now.” I thought this might be a useful topic for a blog.
Tips for Starting an Enterprise Architecture
‘Be the client’ in the present
– Understand why EA considered
– Envision its use
Draft the business environment
– Collect
– Capture
– Consider
‘Be the client’ in the future
– Prepare a brief
– Communicate the possibility
– Adjust and get it done
I recall a discussion or two when I realized that to answer this question one needed to put the answer in the context of the questioner. For example, if the person asking this question was a software developer, the examples I would give would be related to the software development process. Or if the person had a background in building a house (and this has happened), I would attempt to answer in that context – though clumsily I’m sure.
So let’s take a look at a key for starting a software or building project. The most important thing is understanding the prospective end user of the software or the building. So in the case of an Enterprise Architecture project, the first item would be understanding the prospective user of the Enterprise Architecture. For software or a building project, there are known techniques for getting to the end users or habitants that don’t include asking prospective users what they want the software or building to do. Rather they help the prospects discover hidden needs that drive decisions. In these cases, the end users or building inhabitants represent decision makers by answering decisions like: will we successfully be able to use the software? Or will we happily occupy the building?
The above is relevant for an Enterprise Architecture project, though addressing the prospective user can be more confusing. In my opinion, the key is to understand the decisions that need making and the decision makers. Understanding the decision-maker and their type of decisions drives the use of the Enterprise Architecture, and therefore its purpose. Having said this, I believe it is a bad strategy to go and ask the client directly about this – just like in the case above, this is something that is somewhat hidden and the client needs expert help to discover their need for the Enterprise Architecture.
So how do you go about this in practical terms? What I hope is a very practical, and overarching, suggestion is to emerge yourself in the environment of the client(s) involved and empathize.
It is important to understand the reason that the prospective client is considering an Enterprise Architecture – “be the client in the present.” Rarely does a client simply take advice to build an Enterprise Architecture because one day they will need one! So it is important to understand why a client is even considering such a project and putting yourself in their shoes and developing an expert view on how such an asset would be used. (Yes an Enterprise Architecture should be considered an enterprise asset!). Knowing this helps you understand scope, not that you strictly stay within that scope while you are attempting to understand the environment.
You also need to get an understanding of the business environment – “draft the business environment.” By this, I mean collect and dig into everything you can get your hands on about the client. Mine the organizations’ website for things like vision and mission, their public disclosures like financial reports, their organization charts, their strategies and/or operation plans, etc. Of course if you have access to someone inside, mine them for insights in anything they are willing to provide, such as the decision making and/or governance process, operational processes, geographic dispersion, etc. Especially useful are knowing the names of folks who are positive and negative about Enterprise Architecture. This topic leads to a whole blog on its own ;-). Capture the information collected, as draft, using whatever Enterprise Architecture meta-model you use and do so, if possible, in a way that it could be re-used downstream. Now consider and highlight thoughts about how the client can address their original intent in context to what’s been captured. Consider what decisions need to be made to address the intent – make it explicit in what you have captured. Put yourself in their environment- as humbly as possible!
Finally, for this blog anyway, is to communicate your expert opinion on how an Enterprise Architecture can help them address their original intent (even if the contrary!), and, what you currently believe is required for that Enterprise Architecture to be effective – “be the client in the future.” Create a reasonable plan of action to create and use the Enterprise Architecture, one that demonstrates the potential for addressing the intent. Create a briefing that is focused at the business/mission level. Ask for a session to present your thoughts and get the buy-in. In this session, set the expectation that you aren’t expressing anything at this point that is necessarily “right” – be humble. The idea is to get the Enterprise Architecture “right” through the project, not in this preliminary phase. But it is important to get enough right to gain the clients’ confidence! If you are successful getting the confidence you adjust based on session outcomes and continue on!
Of course, much more information is available in The Open Group TOGAF Library!
@theopengroup http://www.opengroup.org
Terence Blevins, a Fellow of The Open Group, is owner of Enterprise Wise LLC and a semi-retired Enterprise Architect. He is currently a Director of The Open Group Governing Board and an active contributor to the Healthcare Forum within The Open Group.
Terry has been involved with the architecture discipline since the 1980s, much of which was done while he was Director of Strategic Architecture at NCR Corporation. Terence has been involved with The Open Group since 1996 when he first was introduced to The Open Group Architecture Forum. He was co-chair of the Architecture Forum and frequent contributor of content to the TOGAF® framework including the Business Scenario Method. Currently he is excited to help the Healthcare Forum work on Boundaryless Healthcare Information Flow.
Terry was Vice President and CIO of The Open Group where he contributed to The Open Group vision of Boundaryless Information Flow™.
He holds undergraduate and Masters degrees in Mathematics from Youngstown State University. He is TOGAF 8 certified.