We are in Public Review!
Welcome to the BTABoK 3.0 (formerly known as the ITABoK), the next release of the BTABoK focused equally on business and technology for architects. We are taking feedback for the full release and are now entering the review cycle so we welcome your comments. The previous published version can always be accessed at ITABoK version 2.0
An engagement model describes how a team of architects interact with an organization, client or internal group. The goal of the engagement model is to best distribute and align an architecture team to create long-lasting value. Many organizations treat this as an enterprise framework adoption problem, but the Iasa Engagement Model goes far beyond frameworks and yet is simpler to understand and implement. The ITABoK engagement model is based on people and outcomes and works with any Enterprise Architecture frameworks in existence. It also includes a simplified framework of tasks, roles and artifacts that can be used either at the project or enterprise level if no other framework is selected. However, it is not the goal of the ITABoK to replace or supersede any existing framework but simply to connect them in a more coherent professionally oriented way.
- The architect roles in an organization
- The architect process and lifecycle
- The architecture tools used
- The architect value proposition
- The architect team layout and interaction with stakeholders
Team Structure and Layout
When managed effectively engagement provides the key to success in architecture teams. It puts a face on the architecture practice with real people. The focus of engagement is on skill delivery at critical points throughout your business which ultimately controls the entire perception of architecture value.
The models we are about to look into haven’t been pulled from thin air. IASA has interviewed many types of organization and has found many common threads to successful engagement model. The first such item is the ratio of architects to IT staff. Most of the architecture teams that report success have the following percentage ratio. For example, in corporate IT a ratio of 5% architect to total IT staff has been reported as the most successful. In team layout, they report that having an architect per project of a certain complexity is key to success.
|Architect to IT staff||5%||8%||6%|
|Team layout||Architect per project||Architect on all customer engagements||Architecture as core to product management|
Scope, context, and roles, discuss the cost of not knowing Scope, context, and roles, review the personal skills analysis questions, discuss the specialized knowledge areas, and consider the various reflection points.
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?
The actions and activities assigned and expected of architects at an organization.
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 you are like most organizations today you will find that it came about and is generally managed very loosely.
When working on your engagement model its good to know how it is normally done. For the most part in industry common roles are defined outside of the company. Accountants, lawyers, finance and business roles 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 basis 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. In the main they don’t govern the role itself but setup 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 etc.
Other questions such as how each individual in the architect role is hired, their skills framework, what constitutes a good or a bad architect and the required background and ongoing education for the architects are simply made up by the internal staff. This is on the main 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.
Managing and Engagement Model
Managing an engagement model requires understanding your architecture initiative from a number of perspectives.
Creating and Maintaining Value Through Architecture
The traditional IT architecture group considered value to be primarily a cost saving excercise with the rest of architecture’s focus on engineering excellence. The Iasa model extends the notion of architect value far beyond that space, while retaining the value generated from traditional architecture capability.
To generate value in the customer it is necessary to describe the value model of Iasa architecture practice.
The first and last thing that you will be known for is your value to the organization. If having an architecture team makes significant profit for the shareholders (whatever their definition of profit is) you will simply never have to worry about them wanting to keep architecture going. However to actually provide value you have to do a number of things.
You have to map your value to understand where it is coming from. You have to demonstrate that regularly and repeat it. Then you have to ensure you are communicating that value to anyone who will listen. Remember its not bragging, it’s simply reporting. For some reason architects tend to not take enough credit for their value. You have to continually review your value and progress and then refactor your engagement approach to map to changing business.
Finding value determines WHERE it is generated and WHEN and WHO was responsible for creation. For example if you are creating software architectures they should be able to demonstrate in numbers exactly how much cost reduction they have done. They should also be able to define how many new capabilities they’ve delivered and what the value of those capabilities is to the business. If the value numbers are low then you need to focus on how to improve them. If they are high figure out how to duplicate them.
What about other mappings such as business, information, infrastructure architecture? Are you even doing those things yet? If not how would their individual value contribute to the whole? If you put advanced business technology strategists at the LOB or business capabilities level they could very likely influence or deliver significant revenue. What about information architects? How would better using, storing or handling information serve the bottom line of the company?
If you are at the enterprise architect level, are you successfully able to provide proactive value at all of these different levels? Are you proactive and rolling up value from all of the different scopes and contexts within you company? Do you have a bottom line value spreadsheet that shows exactly how much money architecture has saved and made for the company? If not, watch out and keep your resume updated.
Process is a key area to consider when building an engagement model. For example, architecture often happens before a project officially gets started. As you can see in the example project portfolio schedules you need to engage both before and after projects as well as understand the engagement across all projects. The portfolio management file attached to the course will help you if you don’t already have a process in place. Remember though architects work on projects we are responsible for technology strategy beyond the project. That means you are not done when it’s over, in fact if 80% of spend on a project happens after it is deployed then your job as a team is just beginning then. The Iasa engagement model supports all types of architecture lifecycles and frameworks including TOGAF, FEAF, Agile and many more.
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.
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.
Typical Engagement Touchpoints
The following section outlines the typical engagement touchpoints via a set of typical lifecycles or processes that exist in most organizations. The assessor should use this as a guide to ensure coverage of engagement; however the naming and specifics that relate to each individual organization mean that the assessor should seek to understand areas where gaps exist or where processes are hidden.
In order to effectively add value to an organization architecture efforts need to be embedded in an organizations existing cycles and processes. The following section describes the areas where architects need to engage in organization.
|Strategic Planning||Ensure the organization strategy is being formulated to ensure most value can be derived from current and future technology|
|Business Planning||Ensure that tactical and operational objectives for the period of the plan can be achieved in a way that derives most value from technology investments while factoring in architectural concerns & constraints|
|Architecture Advisory||Ensure that proposed solutions are best aligned with business outcomes; ensure advisory requesters have a clear understanding of existing capabilities to optimise reuse opportunities and ensure well-governed architecture delivery|
|Architecture Review||Ensure that reviewed architectures are consistent with the current governance and policy, issue waivers when required, request governance updates as identified|
|Architecture Communication||Ensure that architecture successes & activities are clearly and consistently articulated to business and technology personnel|
|Program Management||Identify & ensure that significant architecture requirements are identified and architecture plans are factored into organization programs|
|Project Management||Identify project level architecture considerations and prioritize accordingly, work with project teams to identify appropriate approach and delivery processes and procedures (e.g. ALM)|
|Project Risk Management||Identify significant architectural risk, record, report and manage|
|Demand Management Planning||Collaborate with program management, relationship management and business groups to assess and plan for demand|
|Portfolio Prioritization||Develop/Review business cases to ensure optimal investment mix is selected that will deliver most value to organization|
|Technology Adoption Lifecycle||Identify, track, evaluate and translate future technology for organization|
ITABoK 3.0 by ITABoK 3.0 is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License. Based on a work at https://itabok.iasaglobal.org/itabok3_0/.