Engagement Model

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.

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.

Engagement Defines:

• 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.

	Corporate	Service	Product
Architect to IT staff	5%	8%	6%
Team layout	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

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

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.

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.

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.

People

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.

Artifacts

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.

Type	Example
Document	Office document (Word, Excel, PowerPoint etc.)
Collaboration	Meeting (e.g. ARB, Roadmap envisioning)
Model	Description or representation of a business, process or system
Advisory	Formal advice delivered from ARB
Tool	Architecture Repository, Lifecycle Mgmt, Project Mgmt Tooling
Decision	Decision made by appropriate governance structure (e.g. ISLT, ARB)
Influence	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:

Engagement Management

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.

.