Day 4
Guiding Effective Change
• An Enterprise Architecture (EA) is developed for one simple reason: to guide effective change. • Guidance on effective change takes place during the activity to realize the approved EA. • During implementation, EA is used by the stakeholders to govern change.
How Enterprise Architecture Guides Effective Change
• An architected approach provides a rigorous planning and change governance methodology. • Enterprise Architecture facilitates effective governance, management, risk management, and exploitation opportunities. • It describes the future state and the current state of the Enterprise. • The gap between the Enterprise’s current state and future state highlights what must change.
What an Enterprise Architecture Looks Like
• An Enterprise Architecture (EA) is the set of models, the components, and their relationships that comprise the scope of the EA Landscape under consideration. • It exists to guide and constrain change planning and work to perform the change. • The scope of work embedded in a Request for Architecture Work should identify the applicable characteristics of the EA Landscape.
Models
• Models consistently describe the current and Target Architecture. • The primary purpose of the models is to facilitate the architect to understand the system being examined. • A secondary purpose is re-use.
Architecture Capability (aka EA Capability)
In order to carry out architectural activity effectively within an enterprise, it is necessary to put in place an appropriate business capability for architecture, through organization structures, roles, responsibilities, skills, and processes.
• An EA Capability is the ability to develop, use, and sustain the architecture of a particular enterprise, and use the architecture to govern change. • EA Capability is used here as a management concept that “facilitates planning improvements in the ability to do something that leads to enhanced outcomes enabled by the Capability”.
Governance
• ISO/IEC 38500:2015 defines governance as: “a system that directs and controls the current and future state”. • Governance is a decision-making process with a defined structure of relationships to direct and control the enterprise to achieve stated goals.
Architecture Governance and the Enterprise Architect Role
Two distinct things must be governed and supported by the Enterprise Architect: • The development of the Target Architecture • All change within the scope of the Target Architecture
The Enterprise Architect Role
• The Enterprise Architect supports their organization’s leadership directing and controlling change through the governance of the development of the Target Architecture. • Governance of all change within the scope of the Target Architecture enables to develop a good target that provides an organization’s best achievable course forward. • Typically, the Enterprise Architect and implementer are directed, and both are controlled by the stakeholder.
Architecture Compliance
Ensuring the compliance of individual projects with the Enterprise Architecture is an essential aspect of Architecture Governance. There are usually two complementary processes:
• The Architecture function will be required to prepare a series of Project Architectures • The Enterprise and IT Governance functions will define a formal Architecture Compliance review process for reviewing the compliance of all projects to the Enterprise Architecture
Level of Conformance
• A key relationship between the architecture and the implementation lies in the definitions of the terms “conformant”, “compliant”, etc. • While terminology usage may differ between organizations, the concepts of levels of conformance illustrated in the figure should prove useful in formulating an IT compliance strategy.
Reviews
• An Architecture Compliance review is a scrutiny of the compliance of a specific project against established architectural criteria, spirit, and business objectives. • A formal process for such reviews normally forms the core of an Enterprise Architecture Compliance strategy.
Checklists
Note on Using the Target Checklist
The last question is “Have the stakeholders approved the views?” • If the answer is yes, the governance process is done. • If the answer is no, then there is a decision on whether the Practitioner should rework the architecture or the Architecture Project should be canceled.
The Role of the Architect in Architecture Compliance
Two governance roles are often performed: the Auditor and the Architect.
• Compliance assessment is an auditor role. When non-compliance is identified, the architect needs to produce an impact assessment and recommendation on what to do. • Impact must be assessed on the same terms as the target was developed. Assessing on any other terms invalidates the assessment and recommendation.
Architecture in an Agile Enterprise
• Agile development aligns with ADM Phase G, Implementation Governance • A good Architecture (developed in Phases A-F) will identify what products the Enterprise needs, the boundary of the products, and what constraints a product owner has. • Architecture will have a set of constraints that limit the choices of the Agile team - often termed as guardrails
Focus on Risk Mitigation
• The Practitioner needs to provide support for the change activity. • There should be a focus on risk mitigation, to ensure that the project meets its objectives. • The Practitioner needs to act as the stakeholder’s agent.
Managing Multiple States (Candidate, Current, Transition, and Target)
The Practitioner must track the Architecture states across two characteristics:
• Time • A Conformance Test
Tracking conformance facilitates the Implementation Project and operational change governance.
Managing Complex Roadmaps
Complexity increases when you add in:
• The four characteristics of the EA Landscape: breadth, depth, time, and recency • The different Architecture Projects that can work on the same subject at different times and at different levels of detail
Factors Adding to the Complexity
• Advancements and changes outside the Enterprise • Shared services • Collaboration with suppliers and partners, including portfolio ownership model • Impenetrable dependencies • Multiple geopolitical boundaries (fiscal calendars, regulations, cultures) • Varying rate of maturity and growth of teams • EA team model (federated, centralized, etc.) • Availability of multiple solutions or announcement of end-of-life for products currently in use
Security Architecture
• A structure of organizational, conceptual, logical, and physical components that interact in a coherent fashion in order to achieve and maintain a state of managed risk and security (or information security). • It is both a driver and enabler of secure, safe, resilient, and reliable behavior, as well as for addressing risk areas throughout the enterprise.
Enterprise Security Architecture
• An Enterprise Security Architecture does not exist in isolation. • A close integration of Security Architecture in the Enterprise Architecture is beneficial. • It builds on enterprise information that is already available in the Enterprise Architecture, and it produces information that influences the Enterprise Architecture. • Doing it right the first time saves costs and increases effectiveness compared to bolting on security afterwards.
Security as a Cross-Cutting Concern
• The TOGAF ADM covers the development of the four architecture domains commonly accepted as subsets of an Enterprise Architecture: Business, Data, Application, and Technology. • The Security Architecture interacts with all four of them and is therefore called cross-cutting.
Risk and Uncertainty
• Risk is the effect that uncertainty has on the achievement of business objectives. • Uncertainty typically involves a deficiency of information and leads to inadequate or incomplete knowledge or understanding. • The uncertainty is concerned with predicting future outcomes, given the limited amount of information available when making a business decision. • This information can never be perfect, although our expectation is that given better quality information we can make better quality decisions.
Decision Making Based on Risk Management
Every decision is based on assessing:
• The balance between potential opportunities and threats • The likelihood of beneficial outcomes versus damaging outcomes, • The magnitude of these potential positive or negative events • The likelihood associated with each identified outcome. Identifying and assessing these factors is known as “risk assessment” or “risk analysis”
Risk related Concepts
• “Risk management” is the art and science of applying these concepts in the decision-making process. • Risk can be seen at the strategic long-term level (overall direction of the business), the medium term tactical level (transformation projects and programs), and at the operational level (regular day-to-day operational decisions, processes, and practices). • The objective of risk management is to optimize business outcomes to maximize business value and minimize business losses.
Context I - Individual Founder
• The Individual/Founder context addresses “minimum essential concerns they must address to develop and sustain a basic digital product”. • This context represents the bare minimum requirements of delivering digital value.
Context II - Team
• The team has a single mission and a cohesive identity but does not need a lot of overhead to get the job done. • The Team context covers the basic elements necessary for a collaborative product team to achieve success while remaining at a manageable human scale. • Establishing team collaboration as a fundamental guiding value is essential to successful digital product development. • The team is all in the same location, and can still communicate informally, but there is enough going on that it needs a more organized approach to getting work done.
Context III Team of Teams
• The Team of Teams context is a natural evolution of the Teams context, but one where the number of people and digital products involved generates complexity. • Coordinating across a team of teams is the main concern. • Communication is again key to ensure successful collaboration and value delivery.
Context IV - Enduring Enterprise
The Enduring Enterprise context is about how to manage an enterprise that has been successful and is now faced with the realities of operating a sustainable business over periods of time longer than the next product cycle.
