Working Draft

This site is currently a working draft of the ITABoK 3.0. Release date is planned for beginning of 2017. In the meantime please utilize the current ITABoK version 2.0 

Coverage

If you work for an architecture team, ask yourself how much coverage you are getting on engaging the entire company at all levels. I like to tell architects that  until every employee, partner and consultant can describe the  exact value of the architecture team and you are involved in everything that impacts the technology strategy of the company then you have not fully covered the companies architecture needs. Make that your goal and continue to work towards it.

Progress

You should be managing your engagement model in a proactive manner. Even if the decision is to not have an engagement model for now you will have to update this decision regularly. At a minimum once a quarter you should do a partial or full review of continued growth and strength of  your engagement model including value, skills, education, delivery, process and coverage. This review(s) should be used to modify your model to best meet current needs and opportunities. And don’t forget to market any changes back to the stakeholders! And yes you need to market it and not just inform.

Scope

Think about things that might be included in scope. The reason you must understand this is that scope drastically impacts the roles and structure of your architect team. An enterprise architect may have enterprise level impact but remember that they couldn’t possibly be involved in each actual project. Scope is impacted then by budget, by staff size by complexity or project size and by business impact. Note, in some organizations these may be called aspects.

Since an architecture is a technology strategy then it can be applied at all levels of scope. For example, let’s pretend the sales line of business for a retail company is setting up their strategy for the next year of operations. The VP of Sales would work with marketing, finance and other directors in the sales group to set the strategy. But who would they work with to form the technology vision as a part of that strategy? The business architect. In this instance the business architect would influence each of these stakeholders  but their scope of impact would be the technology value of the entire sales group throughout the coming year including all of the projects that are started because of it and all of the business strategy that is touched by it.

Now flip the last two scenarios in time. If the business architect with the strategy team decided and demonstrated the need for an e-commerce project hand in hand with the software and infrastructure architects, then the software architect would be completing that strategy by delivering the architecture for the commerce project. So the business architect impacts a broader scope of strategy but cannot complete it without other architects. A similar relationship exists between enterprise architecture and the other levels of scope.

In many of the organizations you work with you will find that they modify titles of employees based on the concept of scope and context. We have identified 30-40 different architect titles which is the result of the slight modification of scope, domain or context. For example, security architect may be developed by putting a cross organization view of a single quality attribute.

The scope describes how much strategy you influence. It implies the complexity of the domain (content focus). When designing your engagement model you should  consider the scope of each role and their impact. Does each project have an architect? Do they participate at the LOB level? How do they engage is it proactive or  reactive?

Context

The circumstances and facts surrounding each architect role in an organization as you  can see in the  definition “The set of circumstances or facts that surround a particular event, situation, etc.”

Put in architecture context, The primary set of circumstances or facts that impact the nature and execution of architects within an organization.

  • Business size
  • Business type
  • Business unit
  • Location – geography, language, culture
  • Process and framework
  • SDLC
  • Architecture level
  • Architecture understanding
  • Context impacts architecture capability and role

Things that impact context can generally be classified using a matrix of influences such as business size, type and business unit. For example, large financial institutions tend to have certain character of architecture context when compared with similarly sized retail organizations.

Additional contextual influences are location, including geography, language and culture, process, framework and SDLC levels, current architecture level as well as understanding. Since context effects everything about architecture internally it is important to accurately map these influencers when considering an engagement model.

So a general framework for understanding your context is based on a series of Q/A sessions. How many employees does your business have (this will generally limit the size of  your architect team and engagement)? How much revenue do you  bring in annually? Quarterly? What type of business are you in? What are your customers like? What is the key differentiator of your business? How isstrategy developed? How does  the budgeting process work? What is the IT spend per year and per quarter? What percent is  maintenance vs. new development? Has architecture every been tried there before? If so by whom and when? What happened? What are the processes for SDLC, procurement and project selection?

Capability

The circumstances and facts surrounding each architect role in an organization as you  can see in the  definition “The set of circumstances or facts that surround a particular event, situation, etc.”

Put in architecture context, The primary set of circumstances or facts that impact the nature and execution of architects within an organization.

  • Business size
  • Business type
  • Business unit
  • Location – geography, language, culture
  • Process and framework
  • SDLC
  • Architecture level
  • Architecture understanding
  • Context impacts architecture capability and role

Things that impact context can generally be classified using a matrix of influences such as business size, type and business unit. For example, large financial institutions tend to have certain character of architecture context when compared with similarly sized retail organizations.

Additional contextual influences are location, including geography, language and culture, process, framework and SDLC levels, current architecture level as well as understanding. Since context effects everything about architecture internally it is important to accurately map these influencers when considering an engagement model.

So a general framework for understanding your context is based on a series of Q/A sessions. How many employees does your business have (this will generally limit the size of  your architect team and engagement)? How much revenue do you  bring in annually? Quarterly? What type of business are you in? What are your customers like? What is the key differentiator of your business? How isstrategy developed? How does  the budgeting process work? What is the IT spend per year and per quarter? What percent is  maintenance vs. new development? Has architecture every been tried there before? If so by whom and when? What happened? What are the processes for SDLC, procurement and project selection?