Understanding Engagement Models
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
||Architect per project
||Architect on all customer engagements
||Architecture as core to product management
The Principles of Engagement
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.
The Components of Engagement
Many architect teams are frustrated because architecture and the value an architect brings to a project are not understood. But those architect teams do not perform any root cause analysis to determine what the perception problems are and how the team can mitigate.
By creating standard artifacts and using a common process to manage architecture your team can provide a consistent experience for the stakeholders and alleviate anxiety generated through not knowing what to expect.
As your team determines what people and areas of expertise are available they can work with each other to provide support for each other. By using a common process and set of artifacts your team can determine which are providing value and which need to be modified in order to generate the intended value.
To Iasa people are the most important part of an engagement model. An engagement model with skilled people will be successful even without defined artifacts, processes (frameworks), or management activities, while an engagement model with world class processes, frameworks, management and artifacts will fail with poorly skilled people. Thus, the people portion of an engagement model refers to the skill, motivation, development, experience and overall quality of the architects, titled or otherwise.
Processes and Lifecycles
Architecture engagement models include the processes and lifecycles of the architects within the team. The architect lifecycle is the activities and steps the architects utilize to deliver their value proposition to the customer. Although this value proposition may be delivered utilizing artifacts the architect lifecycle in some organizations is based on collaboration and coordination instead of ownership of artifact creation so artifact creation cannot be seen as the reason for an official architecture lifecycle. The best known and most used Architecture Lifecycle (also known as a methodology) is currently TOGAF’s ADM.
The default Iasa Architect Lifecycle includes 4 phases (Plan, Build, Run, Manage/Value). They are depected here and further explained in the process and lifecycle section of the ITABoK.
The artifacts used in an architect engagement model. They are the outputs of architecture process and lifecycle
The following table lists the sample types of output & types of engagement delivered during each stage in the lifecycle the type is referenced throughout the engagement model indicating how an architect will be involved.
||Office document (Word, Excel, PowerPoint etc.)
||Meeting (e.g. ARB, Roadmap envisioning)
||Description or representation of a business, process or system
||Formal advice delivered from ARB
||Architecture Repository, Lifecycle Mgmt, Project Mgmt Tooling
||Decision made by appropriate governance structure (e.g. ISLT, ARB)
||Any business contact where architecture can be promoted leveraged or presented in the context of delivering business value.
Here is an example from one phase in a corporate members engagement model:
Managing an engagement model includes all steps taken by the leadership to define and manage their engagement success. It includes architecture engagement design and delivery management, value calculation for architect input and techniques used in ongoing improvement to how architects are managed, how decisions about engagement are made and how architects participate in the ownership of their role/job. More information about engagement management can be found in the How to Get Started section of the ITABoK engagement model section.