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?
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
- 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?