How to Set up an Enterprise Architecture Practice

What if someone walked into your office and told you; "you're now in charge of Enterprise Architecture," what would you do? Where would you start? Here are some suggestions...

First, you'd need to be cognizant of the mission implied with such a request. There are in fact two missions that might be involved depending on what type of organization you support. Those missions are:

1. Internal Architecture Management - This mission is focused entirely on supporting internal processes, systems and infrastructure. While these solutions may themselves facilitate core client-facing business capabilities, the architecture group does not directly interact with those clients. This type of EA group or department would of course interact with all other internal organizations and with partners.
2. External Architecture (EA) Consulting - EA Consulting is an entirely customer-facing mission (even though many of the customers you'll have will their own customers). This mission is the one more traditionally associated with the concept of a "Practice." The primary difference between a practice and an internal department is one of flexibility versus absolute subject matter expertise. An EA practice by nature must be able to support any type of organization and thus must be structured for rapid assessment and problem-solving whereas the EA department is more focused on ensuring project success and corporate continuity.

There are some occasions when an EA group may take on both missions, but that's relatively rare (reserved for some of the larger IT consulting companies). Once you understand the primary mission of the EA group you've been tasked to create, then there are five basic steps you'll need to follow in order to get it up and running:

• Step 1 - You'll need to do a thorough assessment of your organization (and its target market). This encompasses quite a lot actually, including - all existing systems, all currently used lifecycle approaches and tools as well as all business processes, goals and the corporate culture/s.

• Step 2 - You'll have to decide what EA means to you and your organization. Rule number 1 about EA - it means different things to different people and no two organizations implement it the same way. In defining what EA means what we're really referring to here is the ability to map EA frameworks, tools or processes to the business culture and environment and then align all of that with corporate expectations. The result is - as we alluded to - always a somewhat unique interpretation of what EA is for that particular organization.

• Step 3 - You'll need to choose, customize or otherwise develop a methodology and align that with the core business objective of your organization. This is one of the hardest parts of setting up an EA group because it usually requires integration with and or rework of existing lifecycle processes.

• Step 4 - You'll need to select what tools you'll be using. On occasion you may actually have the tools you need to start with but that isn't often the case and even when it is those tools are generally underutilized or otherwise lacking in how they're being exploited. Keep in mind that the tool or automation does not in itself make a practice or EA department magically come together - however building an EA group without one is fairly daunting.

• Step 5 - You'll then need to apply and integrate the tools and methodologies with your targeted portfolio of projects and or systems (or clients). This is where the rubber meets the road and where any ROI that might occur should happen. EA that only facilitates strategic planning and isn't fully linked into project architecture is a generally very poor value proposition. EA is ultimately an integration solution but to become that you have to go out and make the necessary connections with all other aspects of the enterprise. 

This of course represents only a very high level overview of what goes into building an EA practice or department - but it does cover some of the most important considerations.


Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc