Contents

1       Overview of the Engagement Terms. 3

2       Framework – Phases. 4

2.1        Imagine – Digital Customer 4

2.2        Become – Digital Business. 5

2.3        Achieve – Digital Employee. 5

2.4        Maximise – Digital Operations. 5

3       Framework – Transitions. 6

3.1        Innovation. 6

3.2        Transformation. 6

3.3        Utilisation. 6

3.4        Measurement 6

4       Architecture Roles. 7

4.1        Enterprise (A-EA) 7

4.2        Solution (A-SA) 7

4.3        Business (A-BA) 7

4.4        Software Architect (A-SWA) 8

4.5        Information (A-IA) 8

4.6        Infrastructure (A-INFA) 8

5       People Model 10

5.1        Skills Inventory (PM-SI) 10

5.2        Organisation (PM-O) 10

5.3        Roles (PM-R) 10

5.4        Extended Teams (PM-ET) 11

5.5        Job Descriptions (PM-JD) 11

5.6        Community (PM-C) 11

6       Value Model 12

6.1        Goals (VM-G) 12

6.2        Business Cases (VM-BC) 12

6.3        Scope and context (VM-SC) 12

6.4        Promoter Score (VM-PS) 13

6.5        Coverage (VM-C) 13

6.6        Technical Debt (VM-TD) 13

6.7        Architectural Analysis (VM-AA) 14

6.8        Quality Attributes (VM-QA) 14

6.9        Value Streams (VM-VS) 15

6.10      Value Methods (VM-VM) 15

7       Operating Model 16

7.1        Services (OM-S) 16

7.2        Assignment (OM-A) 16

7.3        Decisions (OM-DC) 17

7.4        Design (OM-DS) 17

7.5        Stakeholders (OM-SH) 18

7.6        Requirements (OM-R) 18

7.7        Deliverables (OM-DL) 19

7.8        Methodology (OM-M) 19

7.9        Tools (OM-T) 19

7.10      Repository (OM-REP) 20

7.11      Governance (OM-G) 20

7.12      Products (OM-P) 21

7.13      Roadmaps (OM-RM) 21

7.14      Experiments (OM-E) 21

8       Outcomes. 22

8.1        Strategy (O-S) 22

8.2        Agility (O-A) 22

8.3        Business Capabilities (O-BC) 23

8.4        Culture (O-C) 23

8.5        Empowerment (O-E) 24

8.6        Collaboration (O-COL) 24

8.7        Automation (O-AU) 24

8.8        Velocity (O-V) 24

8.9        Simplicity (O-SI) 24

8.10      Ecosystem (O-EC) 25

8.11      Engagement (O-EN) 25

8.12      Journey (O-J) 25

9       Appendix – Cross Reference of Dependencies. 26

1        Overview of the Engagement Terms

The intention of this document is to capture the definitions of all the terms in the Engagement Model.

2        Framework – Outcome Phases and Outcome Spikes

The Engagement Framework is divided into four phases as a cyclical model, based on those used for control, change, problem solving and critical thinking, and originally based around PLAN, DO, CHECK, ACT after Demming and Shewart. https://en.wikipedia.org/wiki/PDCA

The phases or focus areas are used to provide outcome focus to the architecture and business and start with the digital customer (or citizen in government). The phases are broken up by outcome spikes which represent change happening both inside and outside of the organization and which break the cycle up into visible stages for both the internal and external stakeholder.

How does an architect first establish a process for identifying and selecting the right projects for implementation?  How does she convince business partners that the first solution presented is not necessarily the one which will deliver the best value?  How does a technical team describe a roadmap for moving to the cloud for certain systems?  How does a business partner identify enough components of design to start and see an agile development team through to a solution in production?

This section will describe the engagement model – the set of processes and practices the architect will use to operationalize interactions with other roles and teams and implement the rhythm of the architectural approach.  A model – like this engagement model – gives the professional a reference of the most common way her or his peers make sense of a complex environment, whether the architect may be new to an organization or looking to grow the maturity within that organization.  Often a model may form the basis for putting in place practices when no previous model existed or to come up with replacement to ineffective practice.  A model also provides a path to certain outcomes which may be desirable such as improved return on investments, faster decision making and more flexible solutions for future growth.

Description

The engagement model is a combination of 4, interconnected “sub-models” – the first, the outcome model is used to describe the outcomes an organization hopes to achieve as well as the phases necessary to achieve it; one to address the operations of an architecture team, the how the practice of architecture gets done; a third model to understand why we perform the architecture effort and how value is perceived in the organization; and a fourth model describing who the architecture team is, the roles and how to scale the team.  Finally, the engagement model addresses the process steps in the diagram above – a nominal lifecycle – which can be implemented in whole or in part by an organization or can be used to provide continuity between common prescriptive lifecycles used by different teams.

The engagement model has at its centre the architecture roles, surrounded by these four sub-models for people, value and operations, outcomes.  These each evolve through a lifecycle, or sequence of phases, describing how most digital systems evolve from concept to deployment and value realization.

2.1       Imagine – Digital Customer

First digital systems are concepts, in the imagination of an organization’s (potential) customers or business partners.  In the thinking phase we participate in and drive innovation and an understanding of the direction of the organization and how technology impacts its primary objectives in its markets, its products, and its capabilities.  The architect will apply techniques such as business envisioning, customer journeys or service thinking to understand the relative merits of each concept in a structured evaluation, possibly an innovation review.

(Source IASA Document Library)

PP: The digital customer, also digital citizen in government, is the driving force for digital transformation. All innovation starts with creating value for the customer and to do so the architect must understand the ecosystem in which the customer thinks and acts, their journey through their interactions with the organisation and their engagement in the process. The architect team works to achieve innovation in business and employee engagement to create value for the customer.

2.2       Become – Digital Business

As we understand how digital systems work within existing or new business models, they take shape with a specific vision and scope.  We change certain technology strategies and certain business processes in ways that impact the ecosystem of customers the involvement of our customer experience and their journey with our company.  The architect applies envisioning and goal-setting techniques to define the business case for a new solution and assesses our alternatives.

(Source IASA Document Library)

Digital business is derived from the native digital companies that have formed over the last two decades. Building a digital business requires a deep understanding of how technology impacts business models and the capabilities necessary to implement them. From digital health to SAAS companies the digital business focuses on business agility and strategy to allow it to compete for the digital customer. The architects work to transform the business model to achieve customer driven outcomes. The digital business also achieves a new level of sophistication and capability for the digital employee.

2.3       Achieve – Digital Employee

Having selected a solution approach, the architect works within the organization’s culture to establish a team to implement and uses design techniques to socialize the key aspects.  We look at the utilization of these changes how they’ve spread through the digital employee, based and how they’re being adopted by different groups and by the customer themselves.

(Source IASA Document Library)

Achieving a digital employee is no easy task but absolutely necessary in operating a digital business for its customers. Workforce dynamics and culture are all equally different in a transformed business model with its customers. Everything from collaboration to decision making are changed as the business pushes further and further to empower its employees at the edges. The promise of a digital employee is one that can deliver fully on the business model while maintaining operational excellence.

2.4       Maximise – Digital Operations

As the product or solution is implemented, the architect looks to the future – ensuring that the organization is ready for the solution (change management), that the solution is ready for the environment (DevOps), and that the stakeholders can realize the benefits (value realization and governance).  We look at improving and augmenting our operational excellence by reviewing these changes to invest in the next phase of thinking, changing, using, and reviewing.

(Source IASA Document Library)

Digital operations from DevOps through change management are absolutely necessary to maximize the value delivery from Customer, Business, and Employee. Creating a modern landscape for digital operations and ensuring that technical debt remains low or that it is being serviced properly allows the achievement of velocity, simplicity (to the extent possible) and automation are delivered to the organization. The goal of the architecture team is to achieve these outcomes from the single team level all the way through the group’s total outcome set.

3        Outcome Spikes

Each of these phases may overlap as they are implemented, and each often has a defined synchronization point – illustrated by the “spikes” – towards the end, to ensure that the team and the stakeholders are all in agreement.

These spikes represent change points within an organization and may be visible outside as well.  The spikes are Innovation, Transformation, Utilization and Measurement. Innovation and disruption occur both on purpose (from the inside) and from the outside-in and are a direct result of digital strategy. Transformative change also occurs both from the outside and within, indicating what is coming. Utilization (first use) and measurement and are used both positively and negatively by both employees as well as customers, suppliers, partners and the marketplace at large. Together, these four points in the lifecycle determine how rapidly an organization achieves its digital transformation outcomes.

You may look at this initially and see a lifecycle model; after delving into the sections you have the most use for initially, you may return to this model and find quality and maturity aspects to bring to your growing practice.  As a mature architect, you may contribute back to the model your own experiences combining models in your organization and creating a collaborative solution design process.  Through your growth as an architect, the concepts in this engagement model will be explored, brought into your personal practice, and expanded as you adapt them in your organization.

3.1       Innovation

The IT Architecture Organisation is in an exploratory mode, it is identifying areas of creativity and solutions to improve the current organisation state.

PP: Innovation is constantly occurring both inside and outside of the organization. An organizations ability to harness innovation and convert it to strategy within its current business model or by creating new ones, defines its ability to survive through creating value for its customers. Digital innovation is the focus of the ITABoK and the architect teams ability to create and harness it into an effective digital strategy at the multiple scopes in the organization. The team should view its primary focus as the ability to bring the highest total amount of successful digital innovation through transformation and into utilization.

3.3       Utilisation

The IT Architecture Organisation has successfully completed the activities and changes.   The organisation is using the current state in line with the improvement objectives.

PP: Much like the other spikes, utilization is an ongoing process. Utilization is the usage patterns of employees, customers, suppliers, partners and even other systems, where the usage represents both positive and negative outcomes which are consistently being measure either officially or unofficially. These usage patterns define the overall success of the digital transformation and business model. They are measured constantly and concurrently.

3.4       Measurement

The IT Architecture Organisation identifies the Key Performance Indicators and tracks these throughout the engagement life cycle.

PP: Measurement is a set of techniques used to identify positive and negative outcomes throughout the entire change management lifecycle. It is done both officially and unofficially at many levels of scope with the goal of having measurements that roll up into higher levels and form a set of clear indicators of technology contribution to value outcomes. Further levels of measures include the set of external measures used to evaluate the health of a company or a government. As architects measure become a critical factor in understanding the efficacy of technology and business models and are primarily understood through the Value Model.

4        Architecture Roles

This section outlines the definitions for the major IT Architect Roles in IASA.  The Iasa default job descriptions are published as an aid to organizations setting up or reorganizing their architecture practice. These job descriptions in combination with the Iasa skills taxonomy, engagement model, training and certifications serve as the baseline by which organizations may define a robust architecture practice with balanced and focused architecture practices.

4.1       Enterprise (A-EA)

The Enterprise Architect has mastered the fundamental skills in architecture and has been a practicing professional architect within one of the specializations prior to moving into the enterprise architecture practice. The enterprise architect has learned enough of the specializations to lead the architecture teams within an organization. Enterprise architects will have functioned as a solutions architect to the extent necessary to lead at the enterprise or global level. To be an enterprise architect, a successful candidate will have learned the value of the existing specializations and proven their ability to lead the cross-functional architecture teams to success.

The Enterprise Architect is a business technologist in the largest sense of the term. Like all architects they have melded appropriate business and industry understanding to superior skills in technology allowing them to demonstrate value to shareholders and stakeholders alike through the delivery of innovative strategy. They participate as equals in the business strategy development space making technology a fundamental investment tool to meet the organizations objectives. In addition, with their strong business skills they participate in all aspects of business development as partners in process, people and value.

(Source IASA Job Descriptions)

4.2       Solution (A-SA)

The Solution Architect has mastered the fundamental skills in architecture and has been a practicing architect within delivery-based organization. The solution architect is responsible for delivery on one or more projects within the scope of the business case for the solution. Their primary role is to optimize the value of a solution to an organization through delivery and reduce owner risk in its delivery while ensuring the solution meets all compliance and regulatory which impact the system. The solution architect will work with specialist architects, technical staff and stakeholders of the solution to ensure it is delivered or cancelled based on the most effective strategy for the organization as a whole.

(Source IASA Job Descriptions)

4.3       Business (A-BA)

The business architect provides leadership of business initiatives through technology strategy by participating in the development of a business strategy to accomplish specific business goals. They provide innovation and opportunity recognition within business units. Specifically, the business architect has mastered the delivery of value through technology support of business strategy. The business architect has developed their understanding of business valuation, business process and business strategy delivery. They act as a liaison from the technology groups to enhance business development and have tremendously advanced skills in business valuation of technology as well has human dynamics.

The business architect understands the business unit and organization within which they function using both formal methods, such as modelling, as well as informal techniques. They will likely have significant experience within the industry and the particular business function where they work. The business architect functions as a part of the business team as a trusted partner and the models they create may be used to extend beyond just the application of technology strategy as they give useful and powerful pictures of the processes, people and capabilities of the business unit.

(Source IASA Job Descriptions)

4.4       Software Architect (A-SWA)

The software architect has mastered the value, use, development and delivery of software intensive systems. They have developed skills in software development lifecycles, software engineering and software design. The software architect is responsible for the value generated from software systems or system of systems within their direct supervision. They work with project teams to ensure value is delivered for investment and feed resulting valuation results into the business, information and infrastructure areas.

The software architect has fully developed their abilities to understand the costs and revenue generated from software elements as well as the process for delivery. They work through inception alongside business and information architects to ensure that particular business units maximize investment.

(Source IASA Job Descriptions)

4.5       Information (A-IA)

The information architect directs the use, integration and storage of information within a particular business unit (vertical structure) or business capability (horizontal structure). The information architect may focus in on one particular form such as usage focused strategy, information storage or other elements of information architecture or but must consider all elements of information architecture in the organization or customer base. The information architect has mastered the management of information across and within their industry.

Information architects work to ensure that information is used to the best advantage of their organization or customer. Storage and retrieval and integration focus on system to system management and require significant interaction with software and infrastructure architects. Information usability focuses on employee, user or other constituent information requiring significant interaction with business architects.

(Source IASA Job Descriptions)

4.6       Infrastructure (A-INFA)

The infrastructure architect provides strategic uses of infrastructure, network, and operations as an asset. They create and deliver technology strategies to optimize the use of technology resources related to hardware and physical system. It should be noted, this is not meant as quantitative overlap with the upcoming physical system architect who focuses on highly complex physical systems engineering domains such as satellite, defence, and embedded technology though there is some overlap. The infrastructure architect uses their mastery of network, computing platform and operations to guide the organization to valuable investments in hardware and platform.

The infrastructure architect works regularly with business, information and software architects to ensure the overall health of the organizations infrastructure and to optimize technology strategy delivery.  The infrastructure architect has mastered the design, delivery and maintenance of hardware and network technologies throughout the organization.

(Source IASA Job Descriptions)

5        People Model

This defines the terms related to the People Model within the Engagement Model.  The people model includes the skills the architect must have to practice, how the internal architecture team is organized – both for functional alignment to the lifecycle as well as a traditional organization chart with specific quantities of architectural roles – what a nominal job description is for an architect, and what the extended team (roles within the organization which the architect must work with to accomplish the organizational strategy) and the community inside and outside of the organization which supports architecture and is made aware of how the architecture team is operating.

5.1       Skills Inventory (PM-SI)

To deliver value to the organization and operate within the community norms of practicing architects, the team of architects must exhibit certain skills and abilities as a whole and each individual on the team must have minimum, certified skills and abilities to execute their role.  ITABoK defines 5 pillars which group the skills in the architecture community of practice and the most important one is Business Technology Strategy, the ability to understand where the business – sponsor, individuals in the unit, and the trends within competitors – is headed, prioritize and value these ideas, and convert the most important into successfully framed projects.  Each pillar has sub-areas and the ITABoK has over 90 specific skill descriptions generated from the architecture community over the last decade and validated through practice in over 100 organizations.  The IASA Skills Taxonomy is unique in both its detail as well as its ability to connect the specializations together.

(Source Brian)

5.2       Organization (PM-O)

The architecture organization is composed of one or more architects within the parent organization designed to achieve that parent organization’s strategy.  The strategy could be as simple as improving alignment between the business units and IT spend, or it could be more complex as in modernizing business processes or creating new digital products and services.  The architecture organization has a vision and mission statement to orient the work and works in conjunction with other teams in the parent organization on a day-to-day basis.  This architecture team is represented by an organizational chart, by the set of roles, skills, and specializations provided, by its place and interactions throughout the solutions lifecycle, and by its culture.

(Source Brian)

(Source Created for ITABoK 3.0)

5.3       Roles (PM-R)

An architecture role is an expected behavior of an architect at a particular interaction.  This is different than the position or title of architect, which implies certain skills and maturity with carrying out the practice and assigned roles, and the specialization of the architect which adds additional skills in a particular domain of architecture.  An architect may have one or more specializations and may also have one or more roles.  For example, one architect might be specialized as a software architect – building custom coded solutions – and may serve in roles such as a business liaison responsible for coordinating business cases, and as a change management coordinator; another architect may be specialized as a data architect and have roles including project costing and community moderator.

(Source Brian)

5.4       Extended Teams (PM-ET)

Extended teams provide the inputs, outputs and often governance to the architecture organization and are usually outside of the architecture organization itself.  These extended teams provide the complementary engagement pieces necessary for the architect to perform her/his functions.  They should be closely aligned with the parent organization’s strategy and plans, which should also match the architectural organization’s inheritance of this strategy as well.  Some examples of the extended team in an organization where architecture is within the IT function include roles for stakeholders and customers in the business units, support functions like finance and procurement, and internal engagement with the project management office (PMO), development and operations groups.

(Source Brian)

5.5       Job Descriptions (PM-JD)

Job Descriptions describe the context, scope, duties, tasks and deliverables of the IT Architect.   The Job Description will include the position within the organisation from the perspective of deliverables, the IT Architecture Engagement and management reporting.

• Skill required for the Job are defined in terms of IASA 5 Pillars including qualifications and maturity required of the skill to complete the tasks with competence.
• Governance processes will identify RACI (Responsible, Accountable, Consulted and Informed) and the decision rights, these need to be linked to the qualitied Job Descriptions.
• Job Descriptions can be defined for internal and external resources. An organisation may depend on external resources to complete activities they are not always part of the IT Architecture Organisation.

(Source created for ITABoK 3.0)

5.6       Community (PM-C)

The architectural community is a group of individuals who by being in an architectural role or position, by interest, by organizational role outside of the architecture organization, or optionally by being in a local community of interest outside the organization (e.g., a local architecture users’ group) collaborate to improve the practice of an architecture function.  This may be through informal meetings or scheduled analysis and report-out tasks on areas of interest; the community typically does not constitute a governing body.  By not being part of a formal organization chart, the community reinforces the professionality of the architecture practice by conveying needs, gaps, and experience information among practitioners.

(Source Brian)

6        Value Model

This section defines the terms related to the Value Model for the Engagement Model.

6.1       Goals (VM-G)

A goal of all architects should be that every employee, partner and consultant can describe the value of the architecture team and request you be involved in everything that impacts the technology strategy of the company. Until then, your team must understand what can be covered and what governance mechanisms can be put in place to ensure best use of available architectural resources.

By describing the scope of engagement based on roles and organizational visibility you can make sure strong communications are in place. While this drawing suggests the scope of engagement it is not meant to represent a hierarchical communications structure. We urge architecture teams to have open communications link between all levels of architects in the organization.

(Source IASA Core Course)

6.2       Principles (VM-P)

An architecture principle is a declarative statement made with the intention of guiding architectural design decisions in order to achieve one or more qualities of a system

(Source Eoin Woods Presentation)

6.3       Business Cases (VM-BC)

A business case captures the reasoning for initiating a project and what value the project should provide. Architects should verify the value of the technology, add strategy, and make sure the solution fits the governance model, existing portfolio, and can be supported by the Operations group. They can also add value by initiating business cases for projects they feel will add business value. Business valuation, compliance, and decision support skills will help during this phase.

Some things to consider:

• What is the business need?
• What approaches should be considered?

Business cases have some key components, including an executive summary which is normally only one or two paragraphs long and provides high level details of the need and how it aligns with the organization’s business objectives. There will not be many details available so project overview, evaluation, and project selection justification will be high level.

(Source IASA Core Course)

6.4       Scope and context (VM-SC)

Context refers to the circumstances and facts surrounding each architect role in an organization as evidenced 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.”

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 affects everything about architecture internally it is important to accurately map these influencers when considering an engagement model.

(Source IASA Core Course)

6.5       Traceability (VM-T)

This is a method and set of measures used to identify the ability of the organization to trace value through architectural decisions. Traceability in the itabok refers to tracing business goals through business outcomes threaded through the delivery of technology strategy based on rigorous architectural requirements and architectural decisions. It uses coverage, scope and context to understand the number of decisions being made in the enterprise and how they are managed in connection with business outcomes.

(Source created for ITABoK 3.0)

6.6       Risk Methods (VM-RM)

Risk is a measure which relates to the potential of a failure of a system or system of systems and its possible impacts, probability, mitigators and offsets. Risk methods are the mechanism by which the architecture team manages, communicates and handles these risks.

(Source created for ITABoK 3.0)

6.7       Coverage (VM-C)

Coverage is the scope, number of services and deliverables provided by the IT Architecture team in the context IT Architecture Engagement Model.  Organisations categories their business activities into Strategic, Tactical and Operational.   This is mirrored by the IT Architectural Engagement activities of Technology Strategy and Planning (completed by Enterprise Architect), Project and Portfolio Strategy and Planning (completed by the Solution Architect) and Operation activities supported by the other architectural roles.

The coverage at the;

• Strategic level is the complete scope of the Enterprise under evaluation
• Tactical level is the project or system under evaluation
• Operational is the continuous service improvement activities that the IT Architect performs

(Source Created for ITABoK 3.0)

6.8       Technical Debt (VM-TD)

Technical debt (also known as design debt or code debt, but can be also related to other technical endeavours) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.

As with monetary debt, if technical debt is not repaid, it can accumulate ‘interest’, making it harder to implement changes. Unaddressed technical debt increases software entropy. Technical debt is not necessarily a bad thing, and sometimes (e.g., as a proof-of-concept) is required to move projects forward. On the other hand, some experts claim that the “technical debt” metaphor tends to minimize the impact, which results in insufficient prioritization of the necessary work to correct it.

As a change is started on a codebase, there is often the need to make other coordinated changes in other parts of the codebase or documentation. Changes required that are not completed are considered debt, and until paid, will incur interest on top of interest, making it cumbersome to build a project. Although the term is used in software development primarily, it can also be applied to other professions.

(Source : https://en.wikipedia.org/wiki/Technical_debt)

6.9       Architectural Analysis (VM-AA)

One of the keyways architects add value is through structured architecture analysis. Architecture analysis is used as a risk analysis and mitigation technique. The idea is that one we can profitably analyse the proposed architecture for a software system before it has been built, or before major changes to it are made, and discover potential risks to the system which can then be fixed at a low cost (relative to the cost of these risks going undiscovered until the system is developed). Coherence, integrity, quality attribute analysis is all part of this. There are many techniques which can be used to help with this, ATAM is a method for architecture analysis and PBAAM will ensure comprehensive architecture evaluation. (CCB suggestion – include FMEA and Cloud – Amazon well architected – as options)

(Source IASA ITABoK 2.0)

6.10    Quality Attributes (VM-QA)

Quality attributes provide a way for the IT Architect to explore the level of service needed with stakeholders.

• Quality Attributes cut across all IT Architecture concerns also called systemic qualities *ilities
• Examples are Security, Performance, Manageability, Flexibility, Usability, Resilience, Availability, etc.

Additionally, some quality attributes compliment, while other are counter to each other. Iasa organizes key quality attributes under usage related, support related, operation related, and security. This makes it easier to consider attributes you need to consider in your design and provides a way to discuss trade-offs with stakeholders. For instance, providing greater personalization will have a negative impact on supportability. Please note, this is a small portion of the quality attributes that are in use in the industry.

(Source IASA ITABoK 2.0)

6.11    Value Streams (VM-VS)

Value Streams are a series of activities that are performed by the IT Architecture Team as part of their Engagement Model.   Each activity completed must provide some value to the stakeholder.   Value can be measured in terms of revenue, reduced cost, customer satisfaction, reduction in errors, reduced cycle time, etc.

(Source Created for ITABoK 3.0)

6.12    Value Methods (VM-VM)

Value management is the most critical task of the architect. Value figures should be available from business case to business capability measurement. Value should;

• Represent the delta between capability pre and post delivery
• Be rolled up through business, information, software and infrastructure architectures into the enterprise architecture

Architects create models in order to determine what potential approaches should be explored and determine which will provide the greatest value at the lowest risk. These models are typically created at a very high level and are used to help you better explore various aspects of a business case.

(Source IASA Core Course)

7        Operating Model

This section defines the terms related to the Operating Model within the Engagement.

7.1       Services (OM-S)

Services here as they are natural outcomes of capability-based thinking the following are some of the examples of Service Thinking. Services are in this context are not technical elements like SOA or microservices

• Services are what customers want
• A service offered by an Enterprise to its customers or other participants in its ecosystem (suppliers, partners).
• A Service recognized as a Product and offered to Service Consumers on a commercial basis or to support commercial activity
• A service that offers clear value to the consumer but not offered on a commercial basis is also a service.
• A human service offered on a commercial basis as a professional service.
• A service offered to a supplier or partner ‘upstream’ or another ecosystem player on a non-commercial basis.
• A government service offered to a citizen to complete a legally required activity

(Source IASA Solution Architecture Course)

7.2       Assignment (OM-A)

Architecture assignment is the process, methods and goals which describe the way a team of architects engages in work with a customer or organization. It requires more than just assigning an architect on a project or product. It also specifies:

• How architects choose work within the portfolio (or continuous delivery cycle).
• How architects work together to grow in experience, mentor, and ensure success.
• How the team prioritizes work with a client or project management office or agile releases.
• How the team delivers the roadmap.

Assignment Methodology. Depending on organizational maturity and architecture maturity as well as work delivery methodology in use the architecture team must customize their process. Generally, there are three methods in practice at organizations for work assignment with plenty of overlap and situations where multiple methods are in use.

• Stakeholder-Driven Methods
• PMO Methods
• Agile Methods

Understanding Work Priority. Within any method of change priorities must be established to allow the architecture team to assign the most appropriate architect(s).  Once architectural priority is determined architects may be assigned to the work.

(Source Assignment Article)

7.3       Decisions (OM-DC)

IT Architecture is guided by the decisions made as part Strategic Planning, Tactical Planning and Operational/Continuous improvement activities of the IT Architecture Organisation and corresponding Engagement model.  It is critical that these decisions are clearly documented and communicated to the all stakeholders involved.

IT Architecture products and services along with their deliverables are guided by the decisions defined at the following levels.

Setup and Strategic Planning stages will decide the following (they are all decisions that are made);

• IT Architecture Principles
• IT Architecture Policies
• IT Architecture Guidelines
• Technology Standards including associated skill sets

Tactical Planning stage will decide the following (guided from the strategic decisions);

• Solutions or approach to be taken for Architectural Significant Requirements
• Project level architecture decisions including short term technical debt or work arounds
• Requirements traceability decisions for solution components.

Operational and Continuous improvement activities will decide the following (guide by Strategic and Tactical decisions)

• Application evolutionary roadmaps
• Technology evolutionary roadmaps
• Skills and training roadmaps
• Engagement Model operating model improvements

(Source created for ITABoK 3.0)

7.4       Design (OM-DS)

Good design involves justifications, reasons, and trade-off considerations. Many architects think that architecture is the artefacts that are created and that they can reverse engineer architecture. Although they can reverse engineer an existing solution back to the architectural artefacts, they cannot typically determine the reasons decisions were made or what the business requirements were that drove the solution. Although the artefacts are an important part of architecture, the value is in the reasoning and the traceability back to the business requirements.

“Design is the business of finding a way to meet the functional requirements within the specified constraints using the available technology.”— Ensor & Stevenson, 1997

Design is often confused with Unified Modelling Language (UML) or diagrams. The diagrams are the output of the architectural process. Because a number of solutions could satisfy a business need, the reasoning behind picking one approach over another is truly where the value of architecture lies.

Design requires use of techniques, tools, patterns, methodologies, and a host of other tools to help us in providing predictable, repeatable success. We all have bad days, and leveraging tools and methodologies helps us remember what we’ve forgotten to consider in our architecture.

There is both art and science in architecture but leveraging tools and best practices will help you be effective at designing solutions. Almost everything done or accomplished in the architectural field is through design, and certainly when creating the complex solutions required in today’s IT environment.

Design is a human activity, and you are successful in creating architecture when you effectively work with other people and have a common goal or vision. As an architect, you must create a vision that others can understand and support.

• Design is a fundamental human activity.
• Design is the conception and planning of all the products made by human beings.
• Design is creating things intentionally.
• Design is a purposeful creative action.

(Source ITABoK 2.0)

7.5       Stakeholders (OM-SH)

When you consider who the stakeholders are for your project consider who will be impacted by delivery against the project.

• Will there be a group of people that will become irrelevant or displaced when your project is delivered?
• Will the operations team or user support teams have to support new products and processes?
• Will the end users have to learn to do things in a different way?
• Was this project prioritized over another project?
• Is the executive sponsor for your project going to gain visibility over other executives as a result of your project?

There are any numbers of people that can be added to the stakeholder and communications list. Spending the time to compile the list will help the IT Architect craft their communications plan and monitor the progress of their solution.

(Source IASA Core Course)

7.6       Requirements (OM-R)

An architectural requirement is a representation of an architectural concern that impacts the technology strategy.  An architectural constraint is any process, tool, decision or framework that limits choices within a technology strategy.

A requirement is architectural if it:

• Impacts the technology strategy at a level at or above the team defined impact level, or
• It is structurally important to one or more quality attributes, or
• It is important enough to an identified and important stakeholder, or

Develop requirements that impact the technology strategy by ensuring that:

• They are of the appropriate scope (not too low or too high)
• They extract constraints and opportunities to impact actual value

Requirements need to be traced from their source to their final outcome.   This is completed using the requirements traceability matrix.   A requirement may or may not be fulfilled in the solution.  If the requirement is fulfilled the technology, process or manual activity needs to be documented.  If the requirement is not fulfilled that should also be documented as a gap.

7.7       Deliverables (OM-DL)

During each of the phases of the IT Architecture Engagement Model deliverables that have value are created or updated.   Deliverables can be in the form of;

Document or diagram describing decisions made, solution designs, risk register, issues, dependencies, assumptions, views and viewpoints, business cases, roadmaps, outputs from architecture reviews, etc.

Deliverables must demonstrate that value of the IT Architecture Engagement.  Deliverables will be different for;

• Strategic Planning activities
• Tactical/Project activities
• Operational/Continuous Improvement activities

(Source created for ITABoK 3.0)

7.8       Methodology (OM-M)

This is the approach and procedures used to implement and deliver the products and services of the IT Architecture Engagement.   The methodology assumes that the IT Architect will use a set of tools and techniques to successfully deliver value to the stakeholders.

IT Architecture methodology has methods including discovery, problem solving, solutioning and communication.   This will be bound by the principles, policies, standards and guidelines defined during the setup stage of the IT Architecture Organisation.

(Source created for ITABoK)

7.9       Tools (OM-T)

Architecture methods and tools is defined as; the strategic and tactical use of business architecture methods and tools, including but not limited to business process engineering, business process management, business process modelling, workflow, and similar technology in relation to business capabilities and design. Best practices for integrating business processes that span multiple internal organizations.

Architecture Tools;

• Strategy, objective tracking and visualization
• Visualization techniques
• Methodology tracking throughout the life cycle

(Source IASA ITABoK 2.0)

7.10    Repository (OM-REP)

Architecture artefacts are stored in an architecture repository. The repository should be used by all stakeholders and updated regularly. Storage and retrieval are best managed by stakeholder and interest.

A knowledge management process needs to be in place that can be operationalized, consider how long artefacts will be maintained. By setting a date for retirement of an artefact and assigning a role to maintain the repository the IT Architect will help make sure the repository stays fresh and current. The end result will be higher reuse of IP and stronger tendency to store information in a single store.

(Source IASA Core)

7.11    Governance (OM-G)

The decision-making environment for IT within an organization that provides clearly defined roles and responsibilities relative to oversight of projects, processes, and products.

Architects are expected to show competence in designing solutions that achieve regulatory goals and objectives and allow for guidance and oversight that continuously track to the needs of the business.

Governance

• Governance is necessary to ensure delivery against plan
• A technology strategy is only as good as what is delivered
• Architects attach to the existing corporate governance mechanisms
• We are responsible for the COST and VALUE of technology delivered
• Governance defines who, when and how by:
  • Setting up governance bodies which define policies, standards and guidelines regarding a variety of what subjects.
  • Monitoring and enforcing these standards throughout Enterprise

Governance is about decision making when faced with choices (new services, changes to services, retirement of services) based on a set of principles (goals)

• Bringing the right groups of people together to clarify what needs to happen and evaluate what could get in the way (who has decision-making authority?)
• Addresses how expected performance will be evaluated
• Decides priorities and justifiable level of efforts (resource commitments)
• Making it clear what processes and activities should or should not happen
• Seek out risks and provide open discussions and clear approaches to addressing risks
• Ensures compliance by communicating expectations, regulations, policies, and procedures
• Capturing and documenting processes and their results as evidence
• The governance structure will give us a Champion to help address items that impact the workload of stakeholders from outside of our own Branch

Most organizations accomplish IT governance by creating groups, such as steering committees, that bring the right parties together to make decisions on a regular basis.

(Source IASA ITABoK 2.0 and Solution Architecture 2.0)

7.12    Products (OM-P)

A Product is the result of implementation project/initiative, it is how the organisation presents one or more Business Capabilities to the customers, typically it could have a specific cost model associated with it. There might be a difference between how the sales and marketing people describe a Product and a Product Catalogue and how this is delivered within the IT organisation, where a Product Owner controls what is delivered by the engineering team.

(Source: none found, CCB)

7.13    Roadmaps (OM-RM)

The architecture roadmap is a tool used to describe the transition between two states over time and is generally used to show dependencies, milestones, events and other relationships within a set of change initiatives over time. The architect team uses roadmaps in multiple ways to aid in understanding change dependencies.

CCB – There are multiple types of roadmap with different uses:

• Architecture roadmap should focus on how the IT plans meet the business objectives
• Product roadmap will show how new capabilities will delivered over time
• System roadmap will focus on the lifecycle of the systems

7.14    Experiments (OM-E)

IT Architects generally focuses on the Architecturally Significant Requirements (ASR).  These are usually complex problems that have to be resolved and there is no know solution or good practice available.

The IT Architect needs to identify a solution or workable approach to these complex problems/architecturally significant requirements.   The IT Architect has to identify one or more possible solutions to these problems in order to validate the solution they have to perform experiments.

The experiments can either involve new technologies, using existing technologies in a different way, skilling resources to perform the activities or reframing the problem with the stakeholder.   The experiments will typically involve some level of innovation.

(Source created for ITABok 3.0)

8        Outcomes

This section defines the terms related to the Outcomes of the Engagement Model.  Outcomes are consequences of action or inaction and represent a state of being after occurrence of certain changes.  They are commonly changes in individuals, systems, policies, experiences or business conditions.

8.1       Strategy (O-S)

A strategy is simply a plan of actions to achieve one or more important goals, usually communicated at an organizational level.  The goals may be to increase revenue, improve citizen satisfaction, or make a client feel a certain way.  The strategy is often an outcome from a brainstorming and analysis activity and consists of these goals and proposed approaches on how to achieve them in a specific timeframe.  Many strategic frameworks exist, each designed to produce a roadmap or set of outcomes of a certain type.

(Source Brian)

8.2       Agility (O-A)

Agility is the ability to move quickly and easily, this can be applied to an organisation at several levels.

When applied to the Business, agility means the organisation can:

• Adapt quickly to market changes – internally and externally
• Respond rapidly and flexibly to customer demands
• Adapt and lead change in a productive and cost-effective way without compromising quality
• Continuously be at a competitive advantage

Business agility is concerned with the adoption of the evolution of values, behaviours and capabilities. These enable businesses and individuals to be more adaptive, creative and resilient when dealing with complexity, uncertainty and change leading to improved well-being and better outcomes. An agile business is an organisation that embraces the agile philosophy and values at its core, from its people and culture, to its structure and technology. Consequently, an agile business is customer centric.

Agility at the software level defined in the agile manifesto, which aims to uncover better ways of developing software by doing it and helping others do it. Focusing on the core values of:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The architecture must enable both these needs, by focusing on supporting the team to develop the Product with the right Quality Attributes (flexibility, maintainability and scalability) and an evolvable architecture with a cost effective TCO.

(Source adapted from: https://www.agilebusiness.org/page/WhatisBusinessAgility and https://agilemanifesto.org/)

8.3       Business Capabilities (O-BC)

Business Capabilities describe what an organisation does. Advantage Business Capabilities are what make it special.

A business capability is “what” the company needs to be able to do to execute its business strategy. For example, “Set rates based on population characteristics” or “combining elastic and non-elastic materials side by side” are capabilities. ​

Capabilities are operational in nature. Another way to think about them is as a collection or container of people, process, and technology that exist for a specific purpose. ​

Business capabilities are: ​

• Demonstrable: They have defined inputs and outputs. ​
• Addressable: They are independent of other capabilities and organizational boundaries. ​
• Measurable: You can measure their business value and performance characteristics. ​

Capabilities are considered regardless of where they reside inside or outside the organization. ​

An organization’s abilities that have potential for development or use. ​

Characteristics: ​

• Strategic: What an organization needs to do to execute strategy​
• Used to provide focus for taking strategy to action​
• Abstracts or ignores implementation details​
• Very stable; an organization’s capabilities do not change unless the business model changes significantly​

(Source IASA Core Course)

8.4       Culture (O-C)

Culture can be defined as the ethnical culture of a global organization, a technical bias based on the level of comfort and experience with different product stacks or methodologies, or the culture of being risk averse or slow to enact change. Architects must balance between matching their approaches to the culture and moving the various biases in play to introduce change.

Managing the culture is affected by many factors:

• Inter and Intra-team friendships
• Physical barriers
• Methodologies
• Tools such as email vs. surface mail and wiki vs. bulletin board
• Top performers have mastered the art of office politics

(Source IASA ITABoK 2.0)

8.5       Empowerment (O-E)

Empowerment is an outcome focus and measurement point which describes the effective use of decision making and personnel capability utilization within an organization. Through empowering the digital employee, decision making is moved from top-down to organization wide where decisions are made by those most capable and close to a problem or decision point. Used jointly with effective decision management skills it allows an organization to become truly agile. Empowerment also refers to the correct capability management within an organization based on its personnel and their abilities.

8.6       Collaboration (O-COL)

Collaboration and negotiations are leveraging knowledge of the psychology of human collaboration, networking, strategies and methods to facilitate working together and reaching agreement.  Improved cooperation among team members is directly proportional to the level of trust among team members.

(Source IASA ITABoK 2.0)

8.7       Automation (O-AU)

Manual activities and processes are automated using information technology.  Automation provides significant benefits by removing manual tasks, reduces cycle times, errors and costs.

The IT Architect needs to identify tasks that can be automated and implementing solutions where automation will add value to the organisation.   This includes the automation of Knowledge Management and Knowledge worker activities.

Automation between machines within an organisation and across organisational boundaries with companies in the same country or another company in a different region.  The automation needs to consider differences in technologies and standards.

(Source created for ITABoK 3.0)

8.8       Velocity (O-V)

The sustainable rate of change or progress that is required by the organisation.  Businesses and other organisations change at different speeds their hart beat is different.   For example, there are different rates of change with Systems of Engagement (online self-service), Systems of Intelligence (Big data, machine learning, AI) and Systems of Record (Billing and Contract Management).   These are all influenced by the industry or sector.

The Engagement Model needs to apply the correct processes and resources to match the pace of changed required by the stakeholders.   It also needs to align with the implementation methods such as waterfall, Kanban or Scrum being applied by the organisation as part of its change programmes.

(Source created for the ITABoK 3.0)

8.9       Simplicity (O-SI)

The architecture practice should consistently strive for simplicity in its digital operations. Simplicity is the measured ability of the digital footprint to deliver just good enough service to the business model and the customer with just enough complexity to deliver on both measured business outcomes and operational quality attributes within the regulatory or governed environment. It is an effort to constantly remove complexity from a system of systems while retaining customer advantage. Simplicity can be measured through many outcomes related to healthy technical debt, velocity in decisions and value delivery as well as many more.

8.10    Ecosystem (O-EC)

The customer ecosystem is the system of systems which surround and influence the customer or citizen of an organization. It is the set of surrounding context, facts and events which shape a customers interaction with the organization and its partners and competitors. Customer ecosystems can be influenced through effective use of digital strategy and business models to create advantage for the organization and even for the advantage of the entire ecosystem itself.

8.11    Engagement (O-EN)

Engagement defines how architects interact with an organization. It defines how the organization selects and governs its people and what processes they utilize. It is how you map the roles of architecture to the work of architecture which delivers and demonstrates value to the company.

It is in effect how each architect in the company touches the rest of the business officially and unofficially.  In short engagement is everything of significance you do at work.

Engagement Model is a set of conversations, rules and task expectations between a team and their expected partners which align different levels of thinking and strategy

• Organizational or company level – senior leadership with chief architect, with strategic documents/priorities/metrics
• Business unit level – between the sponsors of a project or program and designated subset of architecture team, measured in quarterly milestones and KPI’s
• Execution level – the project team and key individuals as subject-matter-experts, or required for user adoption and a single architect for the project, measured against risk elements and project schedule and stage gates

(Source IASA Core Course)

8.12    Journey (O-J)

The customer journey describes the stages of interaction between a customer and a service and the qualitative aspects which lead to the customer choosing or leaving a given service.  Journeys – sometimes known by their card representation as customer journey map (CJM) – describe a time ordered sequence of stages, connected in the customer’s mind, and include a sentiment or experience measurement.

(Source Brian)