IT Landscape

Enterprise Architecture – Team Size Analysis

I believe there has been increased clarity on the information architecture roles in the recent years. Particularly there are few good healthy discussions on how to develop an enterprise architects and what should be their roles? and what is the value proposition to an organization? In general, there is a better awareness in the senior and executive management teams to differentiate an enterprise architect with other architects (system architects, information architects, business architects, process architects and etc). It has been a challenge for the executives to define the apt size of the enterprise architects for their organization.

The question is: What is the apt size of an enterprise architecture team for an organization?

Consultant Answer: It depends..

Consultant answer is correct.

The real question is: What are the factors used to determine size of an enterprise architecture team in an organization?

The list of enterprise level factors used to determine the size of an enterprise architecture team.

  • Number of products/service provided by the organization
  • Revenue of the organization
  • Profit of the organization
  • Business Process maturity of the organization
  • Finance & controlling maturity level

The list of IT factors used to determine the size of an enterprise architecture team.

  • Number of people (including employees, contractors, consultants, out sourced) and their ratio
  • IT budget and Finance management controls
  • IT Process and system maturity level
  • Enterprise architecture adaption rate (or EA maturity assessment)

Based on the above factors the EA team can be classified as large, medium and small. Large is of team size of 50+, medium is of team size between 15-50 and small is of team size less than 20. Let me emphasis the small EA team. I believe majority of the corporation will come under this category and let me expand on the small size of EA team.

Organization structure for a small size EA Team:

Chief Architect (or manager of EA team) should directly report to the CIO. Along with EA function, IT Finance management, IT Security, SOX controls, vendor management functionalities also should come under the same small size EA team.

(Double click the image to zoom..)

Different types of architects

Architect defines the architecture. Broadly the architects are divided into the technical and business architects. The business architect are focused on the economical change of the market and devise  a set of  business process  for enterprise or systems adaption and to attain enterprise or system’s mission and vision.  The technical architects are  focused on implementation of the business architecture defined to meet enterprise’s or system’s mission and vision.

The technical architects are broadly divided into

    System/Product architect
    Domain Architect
    Solution Architect
    Applied Architect
    Enterprise architect

Based on the architect characteristics, the types of technical architects shall be divided into the generalist and specialist. The specialist focus on one specific area and the knowledge acquired and possessed by the architect is deep. Where as the generalist, knowledge acquired and possessed in a set of areas is broad.
System/product Architect

System/Product architect are the generalist, responsible for the cohesive architecture solution of the system or product. They have equal strength in the both technical and business area. Plays a vital role to bring all the stake holders together and ensure all the stake holders concern’s are captured methodologically, formally documented and validated. Assist the project manager to make the management decision and makes key technical decision for the project/system/product. Brings all the technical architects, development teams, system analyst, and support teams together to ensure the cohesive architecture is defined to meet the stake holders concern and ensures the defined architecture is implemented. The system architecture validation is done by using the user case scenarios. +1 view of the architecture. The architecture verification is done through reviews.

Domain Architect

Domain architects are the specialist, responsible for the architecture solution for that domain. The domain architect is an abstract definition and there are various domain architects. The domain architects specific to the web development projects are

  • Application architect
  • Data architect
  • Information architect
  • Integration architect
  • Security architect
  • IT Process architect
  • Infrastructure architect
    • Network architect
    • Server architect
    • Web run time architect

Solution Architect

Solution architecture team is the set of specialist working together to research and seek solutions for a specific problem.

Applied Architect

Applied architects are match makers. The applied architects have the known set of problems, solution and context. The architectural patterns are applied to the system or product. The architectural patterns includes to the process solution or methodology for the implementation and its style.

Enterprise Architect

Enterprise architect are responsible for defining the holistic architecture solution for the entire enterprise.

How to become an enterprise architect ?

For past few years, quite a few employees, contractors, consultants, right sourcing consultants in the organization asked me this question, what they should do to work for me? In other words, how they could become an enterprise architect. Generally, when someone has this question in the organization, I asked them to schedule a mentoring meeting and try to understand what they want to do and how their aspiration and ambition fits into an enterprise architect’s requirement and coach them accordingly. When this questions became a frequently asked question to me, I decided to document the state transition diagram for an enterprise architect and started providing it to whom ever wants to become an enterprise architect.

I believe this has a value to anyone who wants to become an enterprise architect. This state transition is an ideal road map to become an enterprise architect. When I attended a Gartner conference recently, I informally bounced this idea with fellow enterprise architecture managers, chief architects, chief strategist and most of them agreed that this is the ideal road map for developing enterprise architect talent in an organization.

EA – Make an impact and enjoy

Enterprise Architecture is all about making an impact to the organization in various perspectives like technical, financial, business, organization, information, infrastructure and etc. Making an impact to organization will not happen if some one just does his/her job. EA must enjoy and love their job to make an impact to the organization. The love and joy should not be synthesized but naturally initiated and developed.

The real meaning of success is making an impact and enjoy what you do every day – Dr. Ralph Shrader , Chairman & CEO of Booz | Allen | Hamilton. This concept applies to all the jobs in general. The Enterprise architects in the IT organization are the roles have very high likelihood of making an impact to the IT organization. If you want to be a successful Enterprise Architect and make an impact to the organization, understand the EA, navigate the organization, add value to stakeholders and ENJOY doing it every day.

Delphi Technique – A must have for an Enterprise Architect

Enterprise architect provides a service to internal customers (who are also fellow employees of the same organization). The value of the enterprise architects are demonstrated to the organization by providing value added  consultation and services to the projects team, senior management team and office of CIO. For instance, enterprise architects shall create a technology road map, the future technologies must be used by the organization for any future projects. The project team who wants to follow the road map may not have enough technological exposure to take steps to implement the component of the technology road map in their projects. There may be many reasons not to follow the technology road map by the project teams. The reasons could be political, technical, operational, irrational, and etc. Most frequently the reasons would be presented as rational but the real core reason could be irrational. Until the EA really understands the motive of not following the technology road map, the EA is not going to be successful in the organization. It is a must for a successful enterprise architect to understand the real motive. Why the road maps are not followed? There could be a real issue in following the road map. For instance, if the technology road map indicates to use BPMS for all future projects. The project who understand the technology road map wants to use this technology in their project, but the vendor may be very inflexible in their license, or it could be expensive, there could be resource constraints in the job market and etc. The EA who walk away after creating the road map will not face the problems but their recommendation will not be followed in the organization for legitimate reasons.

Sometimes the reasons would not be legitimate reasons. The project teams do not want take risk by adapting new technology to their project. Could be due to, cost of the resources in the technology, creditability of the EA team, unknown reasons.

It is non technical problem and it is more organizational political problem. There is no logic directly required to solve this kind of problem. When no logic is followed on purpose, then it becomes logical. This topic deserves a separate blog posting. (Topic: ” No logic on purpose is also logical”)

In this case, Delphi technique is one of the best technique to understand why EA recommendation is not accepted and followed. By engaging on the informal discussion with the various stakeholders in the organization and correlating it would provide the insight on the real motive of the key stakeholders for not following the technology road maps.

The technology road map is an example. There are many areas this technique would be followed by EA and IT strategist. There are numerous area where the similar problem exist, delphi technique is a best way to go around and get into the crux of the problem. EA should be mastered in this technique to be the best EA and provide the greater value to their internal customers.

Key deliverables of Enterprise Architecture – High level overview

In an executive summary level, the top 5 Key deliverables of Enterprise Architecture:

  1. Road maps (technology, process, people road maps. Study the maturity,adoption and business application of specific technologies , processes )
  2. Application portfolio management (includes management of “AS IS” information (application, infrastructure, information, business, finance, organization),assessment and recommendation to eliminate over laps)
  3. Scenario Planning (what if analysis for an organization)
  4. Standards & policies (Technology, processes, products,patterns)
  5. IT Risk management (aligned to the enterprise risk management plan)

Enterprise architect provides thought leadership to teams in an organization to believe and implement the above deliverables in their service and solution delivery.

IT Risk Management – An Elevated view

Risk management is part of any management science. (period) Any good project managers do have a risk management plan of a project, team, organization and etc . Risk management plan is part of any management science (yes, I’m repeating myself to stress the point).

CIO‘s are part of the management team and any good (or even an ordinary) CIOs do have a risk management plan for the over all IT organization.

It is a basic principle of business, more risk more profit. At the same time, business is not pure gambling and some time it is calculated gambling. When it comes to gambling, it is taking the chances. When you take the chances blindly, then it is gambling and when you take chances after your due diligence then it is business. May be, I’m over simplifying it but that is the simple definition. If a bank wants to AVOID risk, the ONLY best way to avoid risk 100% is NOT to do business. That is, not performing steps towards their organization goal, mission and vision. Philosophical interpretation is, if you want no complaints then be nothing and do nothing.

Are we not take chances every day? Yes, we take chances every minute. I know some one do not agree what I’m saying. There is a risk of rejection from someone. To avoid it, the best approach is to stop expressing myself. By doing so, I can completely avoid the risk of rejection of my opinions but I can not accomplish my mission (Blog as much I can). The point I’m trying to make is, risk is part of any management science and it should be managed better.

How to manage IT risk better?

Residual risk matrix (RRM) for an IT organization risk is one of key metrics a CIO should have to have a clear picture on probability of exposure. Before I jump into the RRM, let me explain what are the key components of enterprise IT risk management?

Components of enterprise IT Risk management

  • Compliance Risk
  • Infrastructure risk (including data center and business locations)
  • Project Risk
  • Security Risk
  • Financial Risk
  • Technology Risk
  • Process Risk
  • Competency Risk
  • Vendor Risk (service providers like infra service, right sourcing, etc)
  • License Risk
  • Open source Risk
  • Business Risk

Steps to create an enterprise IT residual risk matrix (IT RRM)

  • Identify the known & known unknown risk for each components of the IT risk management
  • Device a mitigation plan for each identified risk
  • Identify the cost of the mitigation plan
  • Identify the probability of the risk occurrence
  • Calculate the risk at exposure (risk exposed to the organization after the mitigation plan)

IT Residual Risk Matrix provides an elevated view to the executive management on the exposed IT risk.