Troux Enterprise Architecture: Managing the EA function

Exclusive offer: get 50% off this eBook here
Troux Enterprise Architecture Solutions

Troux Enterprise Architecture Solutions — Save 50%

Driving business value through strategic IT alignment with this Troux book and eBook

£14.99    £7.50
by Richard J. Reese | August 2010 | Architecture & Analysis Enterprise Articles

This article by Richard J. Reese, author of the book Troux Enterprise Architecture Solutions, explores an aspect of Enterprise Architecture that is not written about a great deal. There are as many models for running the EA function as there are opinions about the topic. This article provides a brief introduction to the following topics:

  • Setting the EA charter
  • Staffing the function
  • Sample job descriptions
  • Management metrics

These topics are provided as representative samples of how the EA function can be managed within a business or agency. There is no "best way" to organize the EA function. There are, however, some management principles that have worked well for many organizations, and these are presented next.

(For more resources on Troux, see here.)

Targeted charter

Organizations need a mission statement and charter. What should the mission and charter be for EA? The answer to this question depends on how the CIO views the function and where the function resides on the maturity model. The CIO could believe that EA should be focused on setting standards and identifying cost reduction opportunities. Conversely, the CIO could believe the function should focus on evaluation of emerging technologies and innovation.

These two extremes are polar opposites. Each would require a different staffing model and different success criteria. The leader of EA must understand how the CIO views the function, as well as what the culture of the business will accept. Are IT and the business familiar with top-down direction, or does the company normally follow a consensus style of management? Is there a market leadership mentality or is the company a fast follower regarding technical innovation? To run a successful EA operation, the head of Enterprise Architecture needs to understand these parameters and factor them into the overall direction of the department. The following diagram illustrates finding the correct position between the two extremes of being focused on standards or innovation:

Using standards to enforce polices on a culture that normally works through consensus will not work very well. Also, why focus resources on developing a business strategy or evaluating emerging technology if the company is totally focused on the next quarter's financial results? Sometimes, with the appropriate support from the CIO and other upper management, EA can become the change agent to encourage long-term planning. If a company has been too focused on tactics, EA can be the only department in IT that has the time and resources available to evaluate emerging solutions. The leader of the architecture function must understand the overall context in which the department resides. This understanding will help to develop the best structure for the department and hire people with the correct skill set.

Let us look at the organization structure of the EA function. How large should the department be, where should the department report, and what does the organization structure look like? In most cases, there are also other areas within IT that perform what might be considered EA department responsibilities. How should the structure account for "domain architects" or "application architects" who do not report to the head of Enterprise Architecture? As usual, the answer to these questions is "it depends".

The architecture department can be sized appropriately with an understanding of the overall role Enterprise Architecture plays within the broader scope of IT. If EA also runs the project management office (PMO) for IT, then the department is likely to be as large as fifty or more resources. In the case where the PMO resides outside of architecture, the architecture staffing level is normally between fifteen and thirty people. To be effective in a large enterprise, (five hundred or more applications development personnel) the EA department should be no smaller than about fifteen people. The following diagram provides a sample organization chart that assumes a balance is required between being focused on technical governance and IT strategy:

The sample organization chart shows the balance between resources applied to tactical work and strategic work. The left side of the chart shows the teams focused on governance. Responsibilities include managing the ARB and maintaining standards and the architecture website. An architecture website is critical to maintaining awareness of the standards and best practices developed by the EA department.

The sample organizational model assumes that a team of Solution Architects is centralized. These are experienced resources who help project teams with major initiatives that span the enterprise. These resources act like internal consultants and, therefore, must possess a broad spectrum of skills.

Depending on the overall philosophy of the CIO, the Domain Architects may also be centralized. These are people with a high degree of experience within specific major technical domains. The domains match to the overall architectural framework of the enterprise and include platforms, software (including middleware), network, data, and security. These resources could also be decentralized into various applications development or engineering groups within IT. If Domain Architects are decentralized, at least two resources are needed within EA to ensure that each area is coordinated with the others across technical disciplines.

If EA is responsible for evaluation of emerging technologies, then a team is needed to focus on execution of proof-of-architecture projects and productivity tool evaluations. A service can be created to manage various contracts and relationships with outside consulting agencies. These are typically companies focused on providing research, tracking IT advancements, and, in some cases, monitoring technology evolution within the company's industry.

There are leaders (management) in each functional area within the architecture organization. As the resources under each area are limited, a good practice is to assume the leadership positions are also working positions. Depending on the overall culture of the company, the leadership positions could be Director- or Manager-level positions. In either case, these leaders must work with senior leaders across IT, the business, and outside vendors. For this reason, to be effective, they must be people with senior titles granted the authority to make important recommendations and decisions on a daily basis.

In most companies, there is considerable debate about whether standards are set by the respective domain areas or by the EA department. The leader of EA, working with the CIO or CTO, must be flexible and able to adapt to the culture. If there is a need to centralize, then the architecture team must take steps to ensure there is buy-in for standards and ensure that governance processes are followed. This is done by building partnerships with the business and IT areas that control the allocation of funds to important projects.

If the culture believes in decentralized standards management, then the head of architecture must ensure that there is one, and only one, official place where standards are documented and managed. The ARB, in this case, becomes the place where various opinions and viewpoints are worked out. However, it must be clear that the ARB is a function of Enterprise Architecture, and those that do not follow the collaborative review processes will not be able to move forward without obtaining a management consensus.

Staffing the function

Staffing the EA function is a challenge. To be effective, the group must have people who are respected for their technical knowledge and are able to communicate well using consensus and collaboration techniques. Finding people with the right combination of skills is difficult. Enterprise Architects may require higher salaries as compared to other staff within IT.

Winning the battle with the human resources department about salaries and reporting levels within the corporate hierarchy is possible through the use of industry benchmarks. Requesting that jobs be evaluated against similar roles in the same industry will help make the point about what type of people are needed within the architecture department. People working in the EA department are different and here's why.

In baseball, professional scouts rate prospects according to a scale on five different dimensions. Players that score high on all five are called "five tool players." These include hitting, hitting for power, running speed, throwing strength, and fielding. In evaluating resources for EA, there are also five major dimensions to consider. These include program management, software architecture, data architecture, network architecture, and platform architecture. As the following figure shows, an experience scale can be established for each dimension, yielding a complete picture of a candidate. People with the highest level of attainment across all five dimensions would be "five tool players".

To be the most flexible in meeting the needs of the business and IT, the head of EA should strive for a good mix of resources covering the five dimensions. Resources who have achieved level 4 or level 5 across all of these would be the best candidates for the Solution Architect positions. These resources can do almost anything technical and are valuable across a wide array of enterprise-wide projects and initiatives.

Resources who have mastered a particular dimension, such as data architecture or network architecture, are the best candidates for the Domain Architect positions. Software architecture is a broad dimension that includes software design, industry best practices, and middleware. Included within this area would be resources skilled in application development using various programming languages and design styles like object-oriented programming and SOA.

As already seen, the Business Architect role spans all IT domains. The best candidates for Business Architecture need not be proficient in the five disciplines of IT architecture, but they will do a better job if they have a good awareness of what IT Architects do. Business Architects may be centralized and report into the EA function, or they may be decentralized across IT or even reside within business units. They are typically people with deep knowledge of business functions, business processes, and applications. Business Architects must be good communicators and have strong analytical abilities. They should be able to work without a great deal of supervision, be good at planning work, and can be trusted to deliver results per a schedule.

Following are some job descriptions for these resources. They are provided as samples because each company will have its own unique set.

Vice President/Director of Enterprise Architecture

The Vice President/Director of Enterprise Architecture would normally have more than 10 or 15 years of experience depending on the circumstances of the organization. He or she would have experience with, and probably has mastered, all five of the key architecture skill set dimensions. The best resource is one with superior communication skills who is able to effect change across large and diverse organizations. The resource will also have experience within the industry in which the company competes. Leadership qualities are the most important aspect of this role, but having a technical background is also important. This person must be able to translate complex ideas, technology, and programs into language upper management can relate to. This person is a key influencer on technical decisions that affect the business on a long-term basis.

Troux Enterprise Architecture Solutions Driving business value through strategic IT alignment with this Troux book and eBook
Published: August 2010
eBook Price: £14.99
Book Price: £24.99
See more
Select your format and quantity:

(For more resources on Troux, see here.)

Director/Manger of Architecture Governance

The Director/Manger of Architecture Governance is responsible for Enterprise Architecture standards and leads the Architecture Review Board (ARB). The resource coordinates approval for proposed architecture designs to ensure projects are aligned with standards and IT strategy. He or she allocates appropriate resources to ensure that projects are completed within committed time and budget and are integrated with other IT architecture projects. The role approves IT architecture policies, standards, and procedures. This person is responsible for the EA Repository and for maintaining the architecture website and other communication channels for the department.

Director/Manager of Solution Architects

The Director/Manager of Solution Architects acts as the ambassador for EA to other teams within IT. This person frequently meets with business leaders to understand and translate business direction into technology requirements. He or she prioritizes and assigns work to Solution Architects. They lead the Solution Architects in development of common frameworks based on industry and internal EA standards. He or she works closely with application development teams to help identify and define technical services that are candidates for reuse across the enterprise. The role mentors other members of IT on the use of internally developed and externally procured software frameworks, tools, utilities, and objects. The resource works with others to establish the messaging standards across the enterprise and verifies that standards are applied to projects on a day-to-day basis.

Solution Architect

The Solution Architect completes work on large and complex IT architecture projects with full competency. The resource is responsible for the major architecture deliverables for enterprise-wide programs and line-of-business projects, including system designs and architecture blueprints. He or she engages Domain Architects regarding hardware engineering, data architecture, and software design best practices. The Solution Architect provides integrated systems planning and recommends innovative technologies that will enhance the current or proposed system designs. The resource recommends appropriate middleware and communication links required to support IT goals and strategy and may coordinate the activities of the project team. Solution Architects assist in monitoring project schedules and costs when asked by project managers.

Director/Manager of Domain Architects

The Director/Manager of Domain Architects is responsible for the integrity of designs provided by domain experts across IT. He or she oversees and coordinates efforts across the various major practice areas of design, regardless of the resources being centralized or decentralized. They attend all ARB meetings and negotiates solutions when disagreements arise regarding design options. The resource is responsible for raising issues to IT management regarding conflicting or disconnected efforts across IT. He or she is responsible for developing compromises and alternatives to resolve design conflicts at the enterprise level.

Director/Manager of Emerging Technology

The Director/Manager of Emerging Technology is assigned with keeping the IT department current on technological advancements. This person leads proof-of-architecture (POA) projects to evaluate emerging technologies. He or she prepares business cases to justify the adoption of new technologies and assists with internal communications leading to successful adoption of leading practices and technologies. The resource is a team member on formalized requests for information (RFIs) conducted by other members within IT and EA. They assist with preparation of RFI documentation and act as lead documentation specialist/ technical writer for various proof-of-concept (POC) efforts. The resource assists in development of communication plans for the EA department.

Research Services Coordinator

The Research Services Coordinator acts as the single point of contact for the research firms on behalf of IT and the business. He or she negotiates and manages research contracts with outside firms and responds to requests for research reports from within IT and from the business. The resource prepares summaries of research information accumulated from various sources for management use. He or she keeps track of research firm utilization statistics and reports on the viability of vendor-provided services. The resource proactively seeks out new sources of information for management and produces periodic updates in newsletter style.

Business Architect

Business Architects are self starters, fast learners, analytical, but are able to communicate well. They are able to produce documentation and make presentations enabling others to understand complex topics. The best job candidates are those with industry knowledge and knowledge of how a particular business operates. They can come from IT or from business areas, but if they come from business areas, should have a high-level understanding of information technology. Their skill set should be focused more on understanding business function than IT infrastructure, but they should be able to relate to both business leaders and IT domain experts equally well.

These are only samples of the types of jobs that may exist within the EA department. Every company has a different view on the overall role of the department. However, by keeping the degree of strategic value desired by upper management in mind, the leader of EA will have developed the correct organization using the most appropriate resource mix to meet the needs of the company.

Knowing how well the department is doing and having the ability to articulate value are also critical challenges for the leader of EA. As the department typically does not build systems or deliver business solutions, justifying the investment for the department is important to the long-term success of the EA function. The following section provides a model for measuring the value of the architecture function.

Management metrics

Because EA is a support function to IT and the business, developing meaningful metrics can be difficult. However, by capturing the appropriate metrics, progress can be measured, value can be calculated, and the group justified. The best way to develop metrics for a support function such as EA is to analyze inputs and outputs of work through the department. What work goes into the team and what deliverables come out? If the group is designed per the examples in this article, work will come into the group in the form of the following:

  • Requests for standards exceptions
  • Requests for architecture assessments
  • Requests for support on new projects
  • Vendor product evaluations
  • Requests for design reviews
  • Support with problem determination
  • Requests for long-term technical plans

Metrics describing work products coming out from EA may include the following:

  • Number of system design documents reviewed
  • Number of standard exceptions granted
  • Number of architecture assessment documents created
  • Number of architecture blueprint documents created
  • Request for information or request for proposals supported
  • Value of systems retired
  • Value of innovative solutions deployed
  • Number of common services developed
  • Savings from common services utilized
  • Problems averted due to design recommendations

While these outputs can be measured, determining their value is difficult. One way to measure value of support services is to survey the customers. After each architecture service is completed, a survey can be sent out asking for input. Surveys can be written to measure if expectations were met on each engagement. A ranking system can be developed for survey results and the grades aggregated to generate a customer satisfaction score.

As EA documents systems within the EA repository, metrics about cost can be captured. How old are the applications? How many IT resources support them? How much infrastructure do they consume (CPU cycles and storage)? All of these metrics can be factored into a formula that determines the real savings of eliminating legacy applications. Enterprise Architecture can also lead efforts for server and data center consolidation. These projects normally yield large savings, clearly justifying the investment in the architecture function.

From a research support perspective, EA can measure research firm usage and identify services that overlap across research vendors. The number of research firms can be consolidated to a few that provide the most benefit and firms that are not used often, or provide similar services to those that are used frequently, can be eliminated.

Enterprise Architecture is responsible for causing changes to occur across the company. As the architecture function matures, a track record can be maintained of new technology and solutions introduced by Enterprise Architecture over time. The following figure provides an example of how EA affects the company over time:

This figure shows that new technology is introduced to the organization in three distinct stages. The introduction stage is led by the EA team. Emerging technology is evaluated and tested. Standards and best practice documents are prepared for solutions that are determined to be important to IT and the business. The architecture team is staffed with resources that are freed up of day-to-day issues, so they can work on evaluating and proving the viability of innovative solutions.

Applying new technology is not easy, as applications development and engineering groups are busy with company priorities. Therefore, it is the job of architecture to prove the new technology and become experts on it to assist with transition. During the transition stage, architecture provides expert assistance to project team members. The best way to move something new into the mainstream is by finding early adopters. These are people in need of innovative solutions to meet their goals. During the transition stage, EA works in an advisory role, as the new technology is adopted by others in the organization.

Sometimes, letting go of a new and exciting solution is difficult for members of the architecture team, but they must; otherwise, they will become a bottleneck to adoption at a later date. Once early adopters have experienced success they spread the word. Word-of-mouth about early success helps "sell" the new solutions to others. Soon, the new technology is being used by many groups and becomes mainstream to the organization in the adoption stage . Once the technology is completely transitioned, architecture need only track compliance to standards and recommended best practices. This adoption life cycle is perpetual and positive effects on the organization can be tracked and measured.

Summary

Establishing the correct focus for the department is a challenge. So is hiring the right people. This article provided a methodology for setting the focus of the organization and then staffing the function accordingly. A sample organization chart was provided. A set of capabilities useful in talent evaluation was described, along with criteria for evaluation of resources. This was followed by sample job descriptions. The article identified performance metrics that are useful in managing the architecture function. A model was provided that tracks innovative solutions from introduction through transition and mainstream adoption.


Further resources on this subject:


Troux Enterprise Architecture Solutions Driving business value through strategic IT alignment with this Troux book and eBook
Published: August 2010
eBook Price: £14.99
Book Price: £24.99
See more
Select your format and quantity:

About the Author :


Richard J. Reese

Richard has 30 years experience working as an Enterprise Systems Architect for some of the largest companies in the world including, Discover Financial Services, IBM (Certified I/T Architect), United Airlines and W.W. Grainger, Inc. Richard led these organizations in major technology transformations resulting in long term improvements in business process flexibility. Richard developed a number of technology strategies and led conversion in the use of massively scalable transaction processing, distributed databases, web-based processing, Service Oriented Architecture, Mobile Banking and large volume decision support. Richard published a book about EA in 2008 (I/T Architecture in Action) and is an experienced speaker.
Richard has a Masters of Business Administration degree from Loyola University of Chicago and a Bachelor’s Degree in Quantitative Information Science from Western Illinois University.e-mail: rjreese@avreservices.com

 

Books From Packt


Service Oriented Architecture: An Integration Blueprint
Service Oriented Architecture: An Integration Blueprint

BPEL PM and OSB operational management with Oracle Enterprise Manager 10g Grid Control
BPEL PM and OSB operational management with Oracle Enterprise Manager 10g Grid Control

Catalyst 5.8: the Perl MVC Framework
Catalyst 5.8: the Perl MVC Framework

MySQL 5.1 Plugin Development
MySQL 5.1 Plugin Development

Oracle SOA Suite 11g R1 Developer's Guide
Oracle SOA Suite 11g R1 Developer's Guide

Microsoft Dynamics NAV 2009 Application Design
Microsoft Dynamics NAV 2009 Application Design

IBM Cognos 8 Report Studio Cookbook
IBM Cognos 8 Report Studio Cookbook

Amazon SimpleDB Developer Guide
Amazon SimpleDB Developer Guide


Code Download and Errata
Packt Anytime, Anywhere
Register Books
Print Upgrades
eBook Downloads
Video Support
Contact Us
Awards Voting Nominations Previous Winners
Judges Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software
Resources
Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software