Mike Walker
July 2007

Summary: Anenterprise architect’s role is multi-faceted and extremely dynamic. Not onlymust they keep track of IT concerns, but also those of the business. Throughthe work performed on strategic initiative, EAs strive to make alignmentbetween IT and the business more transparent.

Contents

Introduction
How this Article is Structured
The Role of an Enterprise Architect
How Enterprise Architects are Different
Tools Enterprise Architects Use
How They Make Decisions
Challenges they Face
Dealing with Governance
Conclusion
References

Introduction

Enterprisearchitecture has grown from being just a set of small pilots to being a fullysponsored and supported initiative within enterprises. With the growing demandsto reduce costs, increase agility, and standardize IT environments, there hasbeen a surge of enterprise architecture activity. According to Gartner and theMIT institute the growing complexities that span across process, informationand software are among the three top CIO concerns. Additional pressures comefrom regulatory bodies that impose compliance guidelines on the industry (suchas the Clinger-Cohen Act of 1996 or FFIEC Guidance). Compliance has been acatalyst for the formation of an enterprise architecture practice. This articlewill walk you through the daily challenges that an enterprise architect faces.By doing so, we hope to provide a unique perspective on this growing role inthe IT industry.

We will take these observations of theenterprise architect role and contrast them with more defined roles in IT, suchas the role of the developer. The enterprise architect (EA) role is bothcomplex and dynamic. After reading this article, you will have a clearerunderstanding of the enterprise architecture role and the challenges faced bythose who fill it. If you are an enterprise architect or aspiring to be anenterprise architect, this is a must-read for you. The guidance found in thisarticle is tailored for mid-size to large enterprises. If you fit other criteria,some or all of the guidance may apply. Prescriptive guidance around enterprisearchitecture strategies, tooling, and governance will not be covered in length.

The term “enterprise architecture” can havemany different meanings, and we often find that there are only particularaspects examined. To compound the issue, information technology professionalsscope  enterprise architecture differently. Some IT professionals viewenterprise architecture as a more structured activity with many moving partssuch as architecture strategy, architecture patterns, principles, architecturedesign, business architecture, and IT governance. Others may just focus on thetechnical aspects rather than the business, operational, or strategic aspects.Many view enterprise architecture as an IT-only issue. In many cases, it isimportant that the enterprise architecture group speak in both business and ITterms. EA should be neutral in their functions.

How this Article is Structured

This article will walk you through the lifeof an Enterprise Architect. To do so, we will surface the following aspects ofthe role:

·        The Role of an EA– In this section we will talk about what it means to be an enterprisearchitect. The skills and the responsibilities that are required to be an EA.

·        How EA’s are Different – We will contrast with various other roles to give a clearerpicture of how EA’s fit within the architecture landscape

·        The Tools they Use – We will get an understanding of what tools are needed in an EAfunction. A scenario will also be given to understand the importance of“connected” EA tooling.

·        How They Make Decisions – We will dive into what happens in the mind of an EA when makingcomplex decisions.

·        How they Fit into the Organization – We will show where EA’s fit into the organization and how theyinfluence our processes and decisions.

·        Challenges they Face – In this section we will talk about the challenges that EA’s faceon a daily basis.

Additionally, we have collected quotesspecifically for this article. They come from the two largest softwarecompanies in the world, Microsoft and IBM. Both IBM and Microsoft havesignificant impact, interest and experience in this area.

The Role of an Enterprise Architect

On a daily basis, an EAs activities canchange quickly and dramatically. For the sake of this article, we will not gointo organizational models of enterprise architecture organizations. Instead,we will explore the role and responsibilities of an enterprise architect.Understanding the role of an enterprise architect will help us understand thechallenges an EA faces on a daily basis.

Figure 1. Enterprise Architecture as defined by Gartner (Click on the picture for alarger image)

Shown above is Gartner’s definition ofenterprise architecture. Unfortunately, this in one of many; there is noconsistent set of definitions for enterprise architecture, which leads tofurther confusion in the industry. For the sake of this article, we will useGartner’s definition as our interpretation of enterprise architecture.

There are a broad range of essential skillsthat every EA should have. Obviously, an EA must be well-educated intechnology. Ideally, EAs should come from a highly technical background. Eventhough enterprise architects deal with many other factors besides technology,it is still important to keep technical skills fresh. Engaging on projects at amicro level of detail can serve as a great refresher from time to time.

Technology skills are not the only skillsyou need to be an EA. There are other skills that are essential, including:

·        Motivational. EAsmust be able to motivate and inspire. A large part of the job is to influenceor evangelize a set of ideals in the enterprise.

·        Negotiation.There will be times at the decision-making table when an EA must negotiate toget things accomplished. Most EAs are individual contributors and do not haveorganizational power.

·        Critical Thinking.Being able to think quickly and on your toes is often required.

·        Problem Solving. EAsoften face a set of complex and unique problems, so they must be able toevaluate and solve problems.

·        Big Thinking.Avoiding tunnel vision and being able to look at a problem from multiple anglesto test your own rationale is crucial to an EAs role.

·        Business savvy.Knowing the industry in which you work is essential, to help you understand howthe technology can really affect the business. Being in tune with the businessgives EAs much-needed credibility.

·        Process Orientation. Thinking in terms of process is essential for an EA. Building repeatable and reusable processes as both as artifacts from the work they do tohow they work themselves.

·        People Skills. AnEA’s job requires interacting with people constantly, so not having those skillscould mean trouble.

Skill sets aside, the role that an EA playsis multi-faceted. The most common function an EA will perform is that oflarge-scale program oversight. Programs are multiple related projectsrepresented as a package. Managing programs generally requires a person that isable to handle multiple aspects of a project at one time.

An EAs role spans more than just strategicor large-scale programs. EAs can also cover the following aspects of a job:

·        Governance Committees. These committees make decisions on what the organizationalstandards and policies should be in an enterprise, such as the supportedprotocols for business partners. There would be very clear business, securityand technology requirements that the governance committee would use todetermine the repeatable patterns, and processes should be employed across theorganization.

·        Architecture Review Boards. Another group of people that convene to approve architecture toensure that it is sound for the organization.

·        Technology Life Cycles. This function determines how individual technologies or standardswill change or be versioned, such as deciding that a Get Customer service willchange every six months and will support two new lines of business every year.They can also determine whether technologies or standards will stay or betransitioned out of the organization.

·        Portfolio Management. Enterprise architects are often linked to and accountable for partor all of the health of the IT portfolio, although they are usuallycontributors to the IT portfolio, not owners. As shown below in figure x.x thisis often refered to this aspect is referred to as Asset Portfolio Management(APM). EA’s add vital information about the technology and provide insightsinto the technology life cycles that govern them.

·        Architecture Strategy. This activity encompasses all or strategic areas of IT. It oftenincludes gathering a current state (asking “What do I have?”), a transitionstate (asking “What iterative steps do I need to get to my goal and what doesthat look like?”), and a future state (asking “What are the changingaspirations of the organization?”).

·        Strategic Project Support. Often, EAs are brought into important strategic projects to aid inensuring the success of the design process.

A good way to compare enterprise architectswith other types of architects is to look at them in terms of breadth vs.depth. This helps us to see the relationship between depth in expertise, suchas depth of understanding in Windows Infrastructure Architecture, and the spanof responsibilities that the architect covers, such as breadth of understandingin a Line of Business (LOB).

How Enterprise Architects are Different

As shown in Figure 3, enterprise architectscover the breadth of IT and, to a degree, the business concerns as well. Whencompared to other roles, you can see that the expertise of an EA is verydifferent.

Let’s take a look at how these roles aredifferent from each other based on breadth vs. depth:

·        EnterpriseArchitect. Enterprise architects span across LOBand IT domains such as security, infrastructure, information, or development.

·        Domain Architect.Domain architects focus on a specific domain and have deep expertise that area.Typically these architects only focus on specific areas, Examples of theseinclude: Business Architect, Security Architect, Information Architect,Infrastructure Architect, Communications Architect, etc.

·        Developer.Developers focus on one solution at a time and have a deep expertise indevelopment.

Figure 3. Architecture roles, breadth vs. depth illustration (Click on the picture for a larger image)

Figure 3 shows an enterprise architect incomparison to other architects. There are many different architecture operatingmodels. The roles shown above are a sample of a structure that demonstrates howeach of these roles might align.

Figure 4. Many different organizational structures (Click on the picture for a larger image)

Figure 4 shows two examples of diversearchitecture organizational models, separated by a line. In some cases theseorganizational models are not hierarchal in nature. Rather, they address thepre-EA operating models. Even though this is not ideal in all cases sometimesit is necessary to gradually introduce change to avoid pushback in theorganization. Each of these can have an impact on the role in which an EAoperates, and each carries contrary organizational and operating challenges.

Clearly, there isn’t just one criterion formaking IT decisions. Decisions are made from multiple perspectives. Often thesedecisions are not made based on the merits of the technology in question but onorganizational aspects such as cost, personnel supportability issues, and ITstandardization.

Tools Enterprise Architects Use

Since EAs have a multi-faceted role, inthis article we will focus on some of the challenges and not all of them holisticallyas the goal of the article is to highlight the day in the life of theenterprise architect.

One of the larger issues with the role ofan EA is having the right tools that enable them to succeed. Since EAs work ata few layers above developers, you will not see developer tools in theirarsenal. What you will find are modeling and communication tools.

You can expect to see the followingapplications in the Microsoft® Windows® Start Menu’s top applications launched:

·        Microsoft Word or Microsoft Excel®, to document and report on architectures

·        Modeling tools (usually Microsoft Visio®), to create models of the architectures

·        Microsoft PowerPoint®, to communicate architectures

·        Management tools,which could consist of internal applications or portfolio management tools

The rest of the tools usually depend on therole of the EA and the standard applications that are used in the organizationfor these functions.

Figure 5. Forrester Research – EA tools used in the enterprise (Click on the picture for a larger image)

The goal now should be to leverage thecapabilities of these tools to optimize your processes. We want to focus on thetooling because the processes and roles are often different from organizationto organization.

Scenario: Using Microsoft Tools for EnterpriseArchitecture

There are many ways you can leverage yourexisting tools without much effort or cost that will give you a substantialgain on your EA productivity. In Figure 6, you can see a sample solution to thedocumentation of enterprise architectures by utilizing standard MicrosoftOffice tools are used to document architectures.

Figure 6. Using Microsoft Office tools in Enterprise Architecture efforts (Click on the picture for a larger image)

In this very high level scenario, you couldbe working on an enterprise effort where you are capturing the current state ofyour enterprise or a project effort. You can create Microsoft Word templatesthat are used for capturing architectures. By doing so, you have definedelements that are consumable by a downstream process for consumption andworkflow.

Many processes can be developed from thisonce the data is in a consumable format. You have created a level ofconsistency in how you document architectures, making it easier to leverageinformation that has been documented when making IT decisions. 

By centralizing the information, you havecreated a repository for all of your architecture information. This facilitatesgovernance functions, such as security, policy management, informationmanagement, approvals, and alerts. Reporting and metrics are a downstreambenefit that can be used after all the information is classified.

How They Make Decisions

Decisions made by Enterprise Architects arecomplex and span multiple domains. EAs are not only pulled into multipledirections but are also required to switch between levels of detail as well. Itis common to go from macro to micro and back again between meetings.

When making architecture decisions, eitheron a project level or enterprise level, there are always many factors that gointo the decision-making process. At times, it consists of a set of compromisesto support a more important factor.

Figure 7. Architecture trade-offs (Click on the picture for a larger image)

As shown in Figure 7, the organizationalfactors can be significant in how technology decisions are made.

In figure 8, you can see that there arethree major classifications of the separation of decision making that is askedof an EA. Depending on your organizational structure, these may look a littledifferent. However, each one of these is important for EAs to advise on.

Figure 8. Three major classifications of the separation of decision making (Click on the picture for a larger image)

Organizational Policy

Policies that span the organization areoften used to facilitate IT governance. By defining a set of policies or rules,the organization is aware of which technology practices are right for theirorganization. When the time comes to do a formal review, the IT community willalso know what will be the basis of their evaluation.

EAs often participate in the committeesthat are responsible for building the overarching policies and standards thatwill be used throughout the enterprise for decision support. The expertise ofan EA in these exercises is extremely valuable, as they have insight into boththe long-term strategy and their organization’s IT landscape.

Organizations have seen significantbenefits by going through this exercise, including:

·        IT cost savings

·        Improved vendor relations

·        Focused IT

·        Empowerment of architects and developers

IT Strategy

Strategy creation is a core function of anEnterprise Architect. There are three base activities that an EA will perform:

·        Defining the future state (sometimes referred to as the “to-be” architecture). This providesa road map for your enterprise to follow. This will also aid in building yourtransition state architectures.

·        Capturing the current state architecture (sometimes referred to as the “as-is” architecture). This activityhelps you figure out “what you have”. By doing this, you can figure out what isworking, identify duplications in the enterprise, or measure the health of keybusiness processes that are supported by your architectures.

·        Building the transition architecture. Transition state architecture is the process by which we connectthe current to the future state by creating an iterative roadmap to get to thedesired future state.

In Figure 9, you can see the IT StrategyLife Cycle. It is important to note that the following activities are notlisted in order.

Capturing current state architectures isessential for grounding your efforts to figure out what needs to be changed ortransitioned. However, it’s best not to capture current state as the firststep. It may seem like a good idea, but it often causes EAs to lose sight ofthe end goal and get lost in the details.

As shown in Figure 9, the lifecycle for ITstrategy is iterative. This means that when you capture your current stateonce, it isn’t necessarily complete. Be careful not to bite off more than youcan chew in each step—divide work into small and consumable chunks to ensuresuccess.

Figure 9. IT strategy life cycle (Click on the picture for a larger image)

When building future state architectures, wetake the current state into account. When the future state models are complete,they can act as a road map that should be used when making technologydecisions. It is an indispensable tool for your architecture thought processesand decisions, because it provides context and perspective about the progressof the architectures in your organization.

Transition state architectures enablefuture state models and plans. It provides changes to the organization ineasily digestible iterative changes. Instead of the “Big Bang” approach whereeverything needs to change at once, this provides a set of steps to move intothe direction of the future state gradually.

As a downstream benefit, it can alsoprovide a test bed for new ideas that may not pan out, so that they can betried with minimal business disruption and financial impact to the business.

The future state is documented mostly inmodels. As shown in Figure 10, this makes it easier to communicate thecomplexities of the architectures.

Figure 10. Source: Gartner - Future State Architecture Roadmaps for Key Microsoft Servers (Click on the picture for a larger image)

When building out future state models, itis important to remember that these are projections of the future. Businesseschange and adapt to industry trends, and they can go in multiple unforeseendirections. It is important to be agile with your EA organization by building adefined life cycle around reviewing the future state architectures.

Program and Project Decisions

When an EA engages with project teams atthis level of decision making, we see a solo view of decision making. Projectteams that are isolated to only a specific LOB often develop these narrowperspectives. This can inhibit an EA’s efforts to unify areas across theenterprise.

Often EAs run into statements such as, “Wehave to have this package” or “We want to build it our way because it works.”Having such a limited view on the decision without considering the biggerpicture is one of the largest reasons why more than 75% of IT work consists ofmaintaining solutions.

When EAs make decisions at this level,reviewing the work done on the organizational policies and IT strategy can savethe day. One effective way to ensure traceability is to create a tool thataligns these components together. This has multiple benefits:

·        Ensures IT decisions are made consistentlyacross the enterprise

·        Creates repeatable process

·        Facilitates traceability to the overall strategyof the organization

·        Empowers architects to make the right decisions

·        Removes the conflict of interest in decisionmaking

·        Enables auditability and accountability of decisionmaking

·        Eases governance

Whether or not you formalize this process,it is important for EAs to take a step back and not focus on the tree, but lookaround the forest and ask some questions, such as:

·        Is this a unique solution, or is there somethingsimilar already in my organization that can be re-purposed?

·        How does this problem align to Buy vs. Build policies?

·        Does this apply just to this domain or multipledomains?

Challenges they Face

There are many aspects of an EA’s job thatdo not involve technology. Often there are organizational considerations orbarriers. As mentioned previously, EAs require essential people skills to besuccessful. Technical savvy is not enough; EAs must also possess greatcommunication skills, be homed in on the business, and be great decisionmakers.

Why are organizational barriers soprevalent in this role?

·        Appetite.Appetite refers to what an organization can support or is willing to support.For example, if one of the organizational principles is to buy software rather thanbuild it, then proposing building a solution may be contrary to what theorganization can support. The ability to support solutions is a factor thatshould always be considered when proposing solutions. Another aspect ofappetite is politics within the organization that will need to be considered.

·        Maturity. OftenEAs have progressive ideas for moving an organization forward with moreadvanced concepts or architectures. However, the organization may not be readyfor those ideas yet, due to factors such as education, infrastructure, andsoftware capabilities. Getting an idea about how mature the organization iswill help EAs propose iterative approaches to advanced concepts and solutions.

·        Incentive.Localized interest—asking “What’s in it for me?” on a personal or team level—isa common organizational barrier. EAs are typically individual contributors andhave little or no organizational powers. When working with teams whoseincentives are based on their own organizational goals, it can be difficult to proposeideas that span the organizational unit.

In addition to complex decision making,there are organizational forces that challenge an EA. These forces often have asignificant impact on an EA’s group, which can lead to poor perception or causean EA’s group to disband into the organization.

There are three core organizationalbarriers that EAs face:

·        Buy-In. Even innon-hierarchal organizations, this is often a challenge. When there are nomanagement ties between you and the personnel you wish to influence, it becomesincreasingly challenging for EAs to accomplish their goals. Gaining buy-in fromyour internal organization on strategies, projects, or their participation onkey activities can be daunting.

·        Resources. Evenif a LOB manager buys in on a strategy, shelling out the cash or personnel tosupport it can be a different story altogether. In many cases, since EAs spanacross the enterprise, there are resource needs not only from that businessowner but from multiple functional areas. To be clear, EAs generally do nothave:

·        Budget. In mostinstances, EA groups have no formal budget, so to be a successful EA you mustbe good at justifying when you need a share of a group’s financial resources.This could be business justification or from an operational perspective.

·        Personnel.Projects need personnel resources as well as financing, so EAs often have to gothrough another justification effort to get IT and business groups to providepersonnel for projects.

·        Influencing Current or Existing Projects. Getting in on the front end of a project is one thing, butinfluencing a project already in motion can be very difficult. In an ongoingproject, teams are often reluctant to take an EA’s input or will bypass EAefforts because of the potential impacts to timelines and incurred cost thatchanges to their architecture may have.

Shown in Figure 11 is Forrester Research’srepresentation of the Enterprise Architect’s Dilemma. This illustration sharessome of the basic themes highlighted above. It provides a good high-levelunderstanding of the organizational barriers.

Figure 11. Forrester’s illustration on the Enterprise Architect’s Dilemma (Click on the picture for a larger image)

Obtaining Buy-In

When obtaining buy-in, it’s usually moreimportant to be able to speak to your audience in terms they understand than todemonstrate the worth of the technology. Most times, this means speaking inbusiness terms. By speaking in business terms, you can qualify and quantify theproblem, and you can clearly show that the change isn’t just a change fortechnology’s sake but rather for a business purpose.

There are very few tools that address thisconcern directly; a combination of resources and tools are most often used,such as.

·        Project Dashboards

·        IT Environment Health and Change ManagementStatistics

·        Business Analytics

·        Current State Architecture Analysis

It is important to collaborate and validateinformation with stakeholders. This ensures buy-in from the stakeholders.Portal tools that allow strategies and the corresponding collateral (such asjustification or metrics) to be published can aid here.

Other tools such as Excel and PowerPointcan also help demonstrate the need for a project.

Getting the Resources

Getting a director or vice president to agreethat you have a good idea doesn’t always equate to getting cash and valuableresources from them. Justifying why you need those resources can be a bigchallenge. EAs must be able to fully explain why someone else should shiftresources, priorities, and budget.

There should be full transparency in theprocess when getting buy-in, preventing any surprises when it comes time to askfor money and personnel.

Influencing Current Projects and Affecting ExistingSolutions

Influencing existing solutions or projectsthat have already been started is very different from obtaining buy-in andresources for a prospective new project. The primary difference is that inthese situations you are affecting work that has already been set in motion,such as a project that has started in a stage of the Software Development LifeCycle or a solution in the IT portfolio. Obtaining buy-in and resourcing isoften performed in the planning stages when resource allocation and funding hasnot been finalized yet. In this case, work has started or is complete. This iswhere negotiation skills are vital.

First, let’s focus on how an EA caninfluence the SDLC processes by interweaving into a current project. Eachorganization usually has slightly different terminology to represent an SDLC;we will use the Microsoft SDLC terminology for this article to keep consistencyof terms. Figure 12 shows the SDLC process and where there are potential touchpoints in the process. Again, the specific naming of the phases may bedifferent in your environment.

Figure 12. Potential Enterprise Architecture touch points in the SDLC process (Click on the picture for a larger image)

Even though an EA could participate inmultiple phases of the SDLC, it doesn’t necessarily mean that they should. EAsmost often engage at the end of the envisioning phase and the start of thedesign phase.

Let’s walk through each phase and highlighthow an EA can help:

·        Envision. Duringthe envisioning phase, there are some critical processes that determine boththe course of the project and the application assets that are to be purchasedor developed. These processes concern how the solution will fit into theenvironment, how it should be architected, and whether an organization shouldbuild, buy, or buy and customize a solution. If vendors will need to beselected, this is a critical stage for an EA to provide input before in-depthvendor management occurs.

·        Design. TypicallyEAs will rely on domain architects and developers to get down to the microlevel of detail. However, EAs need to be able to see how all the pieces fit inthe enterprise and review the architecture as a whole once it is complete.

·        Build. Duringthis phase of application coding, EAs shouldn’t be involved unless there is anexplicit need.

·        Stabilize. Duringtesting cycles, it is inevitable that the application will need to be changedin some way or another. If there are significant changes to the architecture,it may warrant an EA to review the changes and aid the project team to steerthem in the right direction.

·        Deploy. Whengoing through the operational aspects of deploying software to environmentsand instilling change management, EAs shouldn’t be involved unless there is anexplicit need.

·        Production.During this phase, an EA can begin to work with post-production resourcesresponsible for the maintenance of the application. They can build out how thetechnology will be incorporated in the IT portfolio with a subsequent lifecycle, how it will be versioned, build out of left over architecture decisions,if there are any service endpoints or management of endpoint.

Changing existing solutions that havealready been deployed into a live production environment can be a realchallenge. Statements such as “it’s not broken, so why should I fix it?” orsimply “it works and I’m not paying for customizations” are all commonly used,but they are valid statements to address nonetheless.

When EAs move into the post-productionphase of an application’s life cycle, where there are already systems put intoplace, they will find several areas of concern. In Figure 13, you will see thatthere is a great deal to consider.

Figure 13. EA challenges when entering into post-production (Click on the picture for a larger image)

There are impacts to multiple areas, eachof which has its own unique set of challenges. The three major areas thatshould be considered are:

·        Production Processes. These processes support the promotion of software to productionenvironments, change management, and support of solutions after they are inproduction.

·        Production Systems. Systems that are in the production environment are often notisolated; they are deployed and configured into environments that havedependencies and restrictions.

·        Production Teams.Teams that support and deploy these solutions have unique processes andprocedures. There is both a process and an organizational perspective on this.

Production Processes

EAs should be mindful of productionprocesses because they affect the cost, quality, and resiliency of software.EAs can have a positive impact on these processes by being involved in thefollowing core production processes:

·        Configuration Management. EAs can optimize these efforts, both in the design of thearchitecture and in providing insight into the rest of the organization, possiblystandardizing this process.

·        Change Management.EAs are typically not involved in this process, but they need to be mindful ofthe impacts to solutions, since they could have many different relationshipswith other solutions and altering a solution could create downstreamchallenges.

·        Incident Management. EAs do not generally engage in this process either, but they needto be mindful of it, because incident management data can be of great value.The data collected here can correlate with other data to help EAs gauge howmuch an architecture costs.

Production Systems

EAs perform a set of activities thatinvolve existing production systems quite often. By doing so, they servemultiple roles, both in participation and leadership for the followingactivities:

·        Future State Architecture. When EAsdetermine a direction for a set of business problems, a solutions road map andarchitecture envisioning occurs.

·        Current State Review. As mentionedpreviously, EAs generally understand the solution architectures more deeply.This process involves an EA engaging with a LOB owner or post-productionmaintenance teams.

·        Strategic Initiatives. EAs can shape strategic initiatives that result when other forcesbesides a formal planning process trigger evaluation of current solutionarchitectures.

EAs encounter both technology andoperational aspects when reviewing and re-architecting solutions. It’simportant to keep in mind that these concerns are not just related to software,but can include a mix of hardware, communications, and software aspects. Theseaspects stem from a set of enterprise functions, which include:

·        Shared Services.EAs consider whether or not particular solutions should use shared services.

·        Solution Dependencies. Solutions often communicate with other solutions for additionalfunctionality. Unless the current state architecture is fully mapped, there isa seemingly endless amount of interdependencies throughout enterprises.

·        Environments. EAsoften consider unified management and consolidation of platform environments(such as Windows 2003).

·        Constraints. EAstake in limitations or constraints to architectures for various reasons. SomeCOTS-based solutions limit the API usage, for example, while othercustom-developed solutions are built not to be extensible.

Production Teams

Various post-production maintenance teamsare required to do most work on existing architectures, because designdocuments are created during the SDLC process that can quickly become outdated.Unless the architecture is fully documented through the post-production lifecycle, EAs rely on these teams. Teams that are engaged usually consist of:

·        Maintenance Team

·        Operations Team

·        User Support Team

These teams offer perspective into multipledomains of consideration when making architecture decisions.

Dealing withGovernance

Governance facilitates the orderlydevelopment of software in the enterprise by using a set of processes andoperating models, and by policy development. Governance defines the processesby which software should be built. There are multiple aspects to thedevelopment of policy that derive from business drivers, industry trends,competitive forces, and corporate and IT strategy. This article will not gointo great detail into this subject except to discuss how it intersects with theday of an enterprise architect.

After an EA builds policies and standardsand starts to vet them in the enterprise, a governance model emerges.Governance can be tricky, because organizational culture plays a huge part inthis process. Additionally, each organization can have its own model, as shownin Figure 14 - TOGAF Architecture Governance Framework. It highlights the majorstructural elements required for an architecture governance initiative.

Figure 14. TOGAF Architecture Governance Framework - Organizational Structure (Click on the picture for a larger image)

Governance models are solely based onorganizational culture and maturity. This is not a bad thing; it’s actuallyvery good for many reasons. These include:

·        Adapting to the culture of the enterprise

·        Changing perceptions in the organization

·        Allowing resources in the organization to rampup their educationally

IT governance is an activity that EAs areengaged in regularly. It is important to note that day-to-day governanceactivities have a subtle impact on the overall success of an organization, inthe long-term results that yield returns.

Aside from the more formal governancemodel, EAs are usually involved in several governance activities. Theseactivities include:

·        Architecture Reviews. These are usually in the form of committees responsible forevaluating architectures. In this, EAs can address technology standardsadherence.

·        Building of Policies and Standards. Policies and standards are generally built by forming acommittee that has representation from key areas.

·        Creating Design Patterns. Documenting how to employ the policies and standards is essentialto convey the architecture concepts. It also provides the development communitywith building blocks to build compliant architectures.

Falling into the trap of needing to commandand control is a common mistake. Fostering collaboration with the teams is moreeffective than simply telling them what to do. When EAs mandate changeunilaterally, they are viewed as “speaking from an ivory tower” and losecredibility. EAs should enable and empower the community to make the rightdecisions. This gives EAs creditability and support, because they are notviewed as micro-managing.

The end goal should be to raise awarenesswith developers so that they will pay attention to the architecture decisionsthey make when they implement solutions.

Conclusion

An enterprise architect’s role ismulti-faceted and extremely dynamic. Not only must they keep track of ITconcerns, but also those of the business. Through the work performed onstrategic initiative, EAs strive to make alignment between IT and the businessmore transparent.

Being an individual contributor with noalignment to the business or technology LOB group, this often necessitates thatan EA must call more on negotiation skills than technology skills. In this way,EAs must be able to use an ability to influence the organization to do theright thing.

It is important to remember that enterprisearchitecture is about fostering community by providing reusable frameworks fordecision making, repeatable processes, and assistance on mission-criticalprojects.

References

MSDN Enterprise Architecture Center at http://msdn.microsoft.com/architecture/EA