Think about things that might be included in scope. The reason you must understand this is that scope drastically influences the roles and structure of your architect team. An enterprise architect may have enterprise level impact, but remember, he or she couldn’t possibly be involved in each actual project. Scope is affected then by budget, staff size, complexity or project size, and business impact. Note, in some organizations, these may be called aspects.
Think about the commerce project in Figure 48. The architect assigned to the project is dealing with quite a bit to ensure the technology strategy is best realized. Officially, he or she does so by using rigorous communication practices such as the architecture description, which may include different views of the architecture such as the sponsor or project team views in addition to others. (Please note that these views are part of the process and engagement model your company uses).
Capability or Domain Scope
Now let’s take a separate type of scope. Because architecture is a technology strategy, 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 its 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 part of that strategy? The answer is 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 influences 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.
Scope and Roles
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 thirty to forty different architect titles that are 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 impact and scope of each role. Does each project have an architect? Do they participate at the LOB level? How do they engage? Is it proactive or reactive?
There is a lot of risk in setting up an architecture team, especially a pure enterprise architecture team. The primary issue is lack of perception of value due to an inability to cover the full scope of the enterprise. For example, consider an enterprise with 25,000 employees. IT has 2,000 staff and 100–200 concurrent projects per year (from small to very large) and a budget of $20 million. Even with a 1 percent ratio of twenty EA team members, there is very little chance that they could cover all of the projects or engage the entire business. So they end up in a governance and modeling role that ultimately makes it difficult to show any bottom-line value.
- Organization of 25,000
- IT has 2,000 employees
- 100–200 concurrent projects
- IT spend $20 million
- Enterprise architecture has twenty people (1 percent)
- Cannot cover every project
- Cannot engage the entire business
- Only possible activities are governance and modeling
- Makes it very difficult to show value
When I talk about context, I’m referring to 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 the architecture context, this is the primary set of circumstances or facts that affect the nature and execution of architects within an organization.
Things that affect 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; and current architecture level as well as understanding. Because context affects everything about architecture internally, it is important to accurately map these influencers when considering an engagement model.
- Business size
- Business type
- Business unit
- Location—geography, language, culture
- Process and framework
- Architecture level
- Architecture understanding
- Context has an impact on architecture capability and role
Here’s an example mapping of an organization’s context. Compare the following and describe the impacts in the course forum:
- The difference between a US- or small Asian country–based business
- A retail versus a manufacturing company
- A finance-related business unit versus sales
- A TOGAF versus Agile process
- Unified process versus Scrum SDLC
- A company that is just starting to understand and use architecture versus one with ten years of history
- Consider these differences
Let’s look at this a little closer. Most companies have very similar operations and business units. They have a finance group that handles the global ledger, accounting, budgeting, and reporting.
There will be some differences based on their organization type. But as you get into the sales groups, they may drastically differ. You, as an architect, will have to understand where you fit into this equation. Are you externally or internally focused? Service firms often provide external architecture to their clients but often fail to adopt it formally for themselves—a situation we like to call “eating their own dog food.” What other differences might exist based on these two particular architecture contexts?
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 is strategy developed? How does the budgeting process work? What is IT spending per year and per quarter? What percent is maintenance versus new development? Has architecture ever been tried there before? If so, by whom and when? What happened? What are the processes for SDLC, procurement, and project selection?
The answers to these questions define your context.
Now, what about roles? Here’s the definition: “The actions and activities assigned and expected of architects at an organization.” The Free Dictionary: “The actions and activities assigned to or required or expected of a person or group.”
Architect roles define the scope, context, activities, and therefore necessary skills for every single architect at your company. Stop for a minute and think about how those roles were defined. Who created the job definitions and background? Where did the skill set come from and how is it vetted (tested)? If your organization is like most organizations today, you will find that it came about and is generally managed very loosely.
When working on your engagement model, it’s good to know how it is normally done. For the most part, in industry common roles are defined outside of the company. The roles of accountants, lawyers, and finance and business people are well described and have a large infrastructure supporting them. However, for architecture it is normally HR and IT inside the company that define the role.
They sometimes use external bases such as technology trends (think SOA) or frameworks such as TOGAF® to help, but for the most part, they simply make them up based on the knowledge and experience of the internal staff. Overall, they don’t govern the role itself but set up a series of implicit and explicit goals that the architects must meet. In some cases, they include the history of the role as they see it, such as a focus on software engineering.
Other questions such as how individuals in the architect role are hired, what their skills framework is, what constitutes a good or a bad architect, and whether they have the required background and ongoing education are simply made up by the internal staff. This is usually how architecture is managed. In the next module, we will talk about a way to do it that is based on more standardized staff management models found in finance, sales, and HR.