The role of solution architecture is to identify answer to a business problem and set of solution options and their components. There will be many potential solutions to a problem with varying degrees of suitability to the underlying business need. Solution options are derived from a combination of Solution Architecture Dimensions/Views which describe characteristics, features, qualities, requirements and Solution Design Factors, Limitations And Boundaries which delineate limitations. Use of structured approach can assist with solution design to create consistency. The TOGAF approach to enterprise architecture can be adapted to perform some of the analysis and design for elements of Solution Architecture Dimensions/Views.
Integrated Project and Solution Delivery And Business Engagement ModelAlan McSweeney
Projects are a continuum from initial concept to planning, design, implementation and management and operation of the implemented solution (and ultimate decommissioning) and across IT and business functions.
Therefore it is important to have an integrated project delivery approach that crosses these core dimensions.
This describes an integrated approach to solution delivery encompassing Stages - project stages/timeline, Activities - IT and business functions/ roles/ activities, Gates - project review and decision gates and Artefacts - project results and deliverables. This combines project management into all other aspects and activities of project and solution delivery:
• Business
• Business Analysis
• Solution Architecture
• Implementation and Delivery
• Test and Quality
• Organisation Readiness
• Service Management
• Infrastructure
It emphasises early business engagement and solution definition and validation to detail a solution that meet a clear and articulated business need that will deliver a realisable and achievable set of business benefits. It ensures that the complexity of what has to be delivered is understood so there is a strong and solid foundation for solution implementation, delivery and management and operation.
Digital Transformation And Solution ArchitectureAlan McSweeney
Digital strategy is a statement about the organisation’s digital positioning, competitors and customer and collaborator needs and behaviour to achieve a direction for innovation, communication, transaction and promotion. Digital strategy needs to be defined in the same framework structure as the proposed digital architecture platform.
Achieving the target digital organisation means deploying solutions that enable the digital architecture. Solution architecture needs to design solutions that fit into the target digital architecture framework. This requires:
• Solution architecture team operating in an integrated manner designing solutions to a set of common standards and that run on the platform
• Solution architecture team leadership ensuring solutions conform to the common standards
• Solution architecture technical leadership to develop and maintain common solution design standards
• Solution architecture updates the digital reference architecture based on solution design experience
Digital solution design requires greater discipline to create an integrated set solutions that operate within the rigour of the digital architecture framework. The solution architecture function must interact with other IT architecture disciplines to ensure the set of solutions that implement the digital framework operate together. This requires greater solution architecture team leadership. This needs to be supplemented and supported by a well-defined set of digital solution design standards.
This follows-on from the previous presentation: Digital Transformation And Enterprise Architecture
https://www.slideshare.net/alanmcsweeney/digital-transformation-and-enterprise-architecture.
Why Solutions Fail and the Business Value of Solution ArchitectureAlan McSweeney
This is an extract from the book introduction to Solution Architecture that provides a solution architecture perspective on why solution delivery fails. It is a reasonable statement that in the minds of many people failure is synonymous with information technology projects. While this perception is an exaggeration, the outcomes of many IT solution delivery projects represent failures to at least some extent. It is also often true that solution delivery failure is attributed to project management failure such as the quality, skill and experience of the project manager or the misapplication or lack of application of a project management methodology. However, the most effective project management will not make an undeliverable, unworkable, unusable solution deliverable, workable or usable. The solution architect should concern himself or herself with the ultimate success of the project to deliver the designed solution.
Integrated Project and Solution Delivery And Business Engagement ModelAlan McSweeney
Projects are a continuum from initial concept to planning, design, implementation and management and operation of the implemented solution (and ultimate decommissioning) and across IT and business functions.
Therefore it is important to have an integrated project delivery approach that crosses these core dimensions.
This describes an integrated approach to solution delivery encompassing Stages - project stages/timeline, Activities - IT and business functions/ roles/ activities, Gates - project review and decision gates and Artefacts - project results and deliverables. This combines project management into all other aspects and activities of project and solution delivery:
• Business
• Business Analysis
• Solution Architecture
• Implementation and Delivery
• Test and Quality
• Organisation Readiness
• Service Management
• Infrastructure
It emphasises early business engagement and solution definition and validation to detail a solution that meet a clear and articulated business need that will deliver a realisable and achievable set of business benefits. It ensures that the complexity of what has to be delivered is understood so there is a strong and solid foundation for solution implementation, delivery and management and operation.
Digital Transformation And Solution ArchitectureAlan McSweeney
Digital strategy is a statement about the organisation’s digital positioning, competitors and customer and collaborator needs and behaviour to achieve a direction for innovation, communication, transaction and promotion. Digital strategy needs to be defined in the same framework structure as the proposed digital architecture platform.
Achieving the target digital organisation means deploying solutions that enable the digital architecture. Solution architecture needs to design solutions that fit into the target digital architecture framework. This requires:
• Solution architecture team operating in an integrated manner designing solutions to a set of common standards and that run on the platform
• Solution architecture team leadership ensuring solutions conform to the common standards
• Solution architecture technical leadership to develop and maintain common solution design standards
• Solution architecture updates the digital reference architecture based on solution design experience
Digital solution design requires greater discipline to create an integrated set solutions that operate within the rigour of the digital architecture framework. The solution architecture function must interact with other IT architecture disciplines to ensure the set of solutions that implement the digital framework operate together. This requires greater solution architecture team leadership. This needs to be supplemented and supported by a well-defined set of digital solution design standards.
This follows-on from the previous presentation: Digital Transformation And Enterprise Architecture
https://www.slideshare.net/alanmcsweeney/digital-transformation-and-enterprise-architecture.
Why Solutions Fail and the Business Value of Solution ArchitectureAlan McSweeney
This is an extract from the book introduction to Solution Architecture that provides a solution architecture perspective on why solution delivery fails. It is a reasonable statement that in the minds of many people failure is synonymous with information technology projects. While this perception is an exaggeration, the outcomes of many IT solution delivery projects represent failures to at least some extent. It is also often true that solution delivery failure is attributed to project management failure such as the quality, skill and experience of the project manager or the misapplication or lack of application of a project management methodology. However, the most effective project management will not make an undeliverable, unworkable, unusable solution deliverable, workable or usable. The solution architect should concern himself or herself with the ultimate success of the project to deliver the designed solution.
The latest version of the TOGAF standard has special emphasis on Business Architecture, Digital Trends, and Business Transformation beyond IT. Stuart Macgregor takes us through some of these changes to the TOGAF® 9.2 standard and discuss how they will benefit us.
Review of Information Technology Function Critical Capability ModelsAlan McSweeney
IT Function critical capabilities are key areas where the IT function needs to maintain significant levels of competence, skill and experience and practise in order to operate and deliver a service. There are several different IT capability frameworks. The objective of these notes is to assess the suitability and applicability of these frameworks. These models can be used to identify what is important for your IT function based on your current and desired/necessary activity profile.
Capabilities vary across organisation – not all capabilities have the same importance for all organisations. These frameworks do not readily accommodate variability in the relative importance of capabilities.
The assessment approach taken is to identify a generalised set of capabilities needed across the span of IT function operations, from strategy to operations and delivery. This generic model is then be used to assess individual frameworks to determine their scope and coverage and to identify gaps.
The generic IT function capability model proposed here consists of five groups or domains of major capabilities that can be organised across the span of the IT function:
1. Information Technology Strategy, Management and Governance
2. Technology and Platforms Standards Development and Management
3. Technology and Solution Consulting and Delivery
4. Operational Run The Business/Business as Usual/Service Provision
5. Change The Business/Development and Introduction of New Services
In the context of trends and initiatives such as outsourcing, transition to cloud services and greater platform-based offerings, should the IT function develop and enhance its meta-capabilities – the management of the delivery of capabilities? Is capability identification and delivery management the most important capability? Outsourced service delivery in all its forms is not a fire-and-forget activity. You can outsource the provision of any service except the management of the supply of that service.
The following IT capability models have been evaluated:
• IT4IT Reference Architecture https://www.opengroup.org/it4it contains 32 functional components
• European e-Competence Framework (ECF) http://www.ecompetences.eu/ contains 40 competencies
• ITIL V4 https://www.axelos.com/best-practice-solutions/itil has 34 management practices
• COBIT 2019 https://www.isaca.org/resources/cobit has 40 management and control processes
• APQC Process Classification Framework - https://www.apqc.org/process-performance-management/process-frameworks version 7.2.1 has 44 major IT management processes
• IT Capability Maturity Framework (IT-CMF) https://ivi.ie/critical-capabilities/ contains 37 critical capabilities
The following model has not been evaluated
• Skills Framework for the Information Age (SFIA) - http://www.sfia-online.org/ lists over 100 skills
During last few years, role of Enterprise Architecture has expanded from technical to strategic in an Organization. This slide deck presents: Using Enterprise Architecture in your Organization.
Digital Transformation And Enterprise ArchitectureAlan McSweeney
Digital transformation - extending and exposing business processes outside the organisation - by implementing a digital strategy – a statement about the organisation’s digital positioning, operating model, competitors and customer and collaborator needs and behaviour through the delivery of digital solutions defined in a digital architecture – a future state application, data and technology view to achieve digital operating status - is potentially (very) complex.
Digital architecture does not exist in isolation entirely separate from an organisation’s overall enterprise architecture. Digital architecture must exist within the within the wider enterprise architecture context.
Enterprise architecture provides the tools and the approaches to manage the complexity of digital transformation.
The management function that drives digital transformation needs to involve the enterprise architecture function in the design and implementation of digital strategy and organisation, process and policies and the creation of a digital architecture. Management must appreciate the technology focus and the benefits of an enterprise architecture approach.
The early involvement of enterprise architecture increases successes and reduces failures. Management must trust and involve enterprise architecture. The enterprise architecture function must accept and rise to the challenge and deliver. The enterprise architecture function must allow its value to be measured.
What is the Value of Mature Enterprise Architecture TOGAFxavblai
Judith Jones received the Open Group award for Outstanding Contributions to the development of TOGAF 9 at 19th Open Group Enterprise Architecture Practitioners Conference Chicago - July 21-23, 2008. Former CEO of Architecting the Enterprise which has been a member of The Open Group for 6 years, she is personnally involved since 1997. As an active member of The Open Group and she is a major contributor and an editor of TOGAF 7, 8 and 9 as well as leading TOGAF projects for localisation, case studies, ADML, synergy and collaboration projects.
http://www.opengroup.org/member/member-spotlight-jones.htm
It is well known that an effective PMO is key to successful and efficient program and project execution. In other words, doing things “right”. Enterprise Architecture is the discipline that plans and monitors enterprise transformation and aligns the business strategy with information technology capabilities. In other words, doing the “right things” to support the business.
Why is it organizations despite having both of these disciplines still struggle with effective enterprise transformation? What can we done to use these disciplines more effectively to effect better business outcomes? What are the roles of each discipline and how do they work together to create business value?
In this presentation, Riaz will address these questions and will provide real life examples that can help build a strong relationship between the PMO and Enterprise Architecture.
Learning Objectives:
• How to build a strong relationship between the PMO and Enterprise Architecture (EA) to deliver positive outcomes for your organization
• Identify the different roles and functions of the PMO and EA as well as their similarities
IT Architecture’s Role In Solving Technical Debt.pdfAlan McSweeney
Technical debt is an overworked term without an effective and common agreed understanding of what exactly it is, what causes it, what are its consequences, how to assess it and what to do about it.
Technical debt is the sum of additional direct and indirect implementation and operational costs incurred and risks and vulnerabilities created because of sub-optimal solution design and delivery decisions.
Technical debt is the sum of all the consequences of all the circumventions, budget reduction, time pressure, lack of knowledge, manual workarounds, short-cuts, avoidance, poor design and delivery quality and decisions to remove elements from solution scope and failure to provide foundational and backbone solution infrastructure.
Technical debt leads to a negative feedback cycle with short solution lifespan, earlier solution replacement and short-term tactical remedial actions.
All the disciplines within IT architecture have a role to play in promoting an understanding of and in the identification of how to resolve technical debt. IT architecture can provide the leadership in both remediating existing technical debt and preventing future debt.
Failing to take a complete view of the technical debt within the organisation means problems and risks remained unrecognised and unaddressed. The real scope of the problem is substantially underestimated. Technical debt is always much more than poorly written software.
Technical debt can introduce security risks and vulnerabilities into the organisation’s solution landscape. Failure to address technical debt leaves exploitable security risks and vulnerabilities in place.
Shadow IT or ghost IT is a largely unrecognised source of technical debt including security risks and vulnerabilities. Shadow IT is the consequence of a set of reactions by business functions to an actual or perceived inability or unwillingness of the IT function to respond to business needs for IT solutions. Shadow IT is frequently needed to make up for gaps in core business solutions, supplementing incomplete solutions and providing omitted functionality.
This examines the potential for the application of Design Science principles to the solution design process within solution architecture to improve the rigour and accuracy of solution designs.
Design Science is the structured and systematic process for creating designs that resolve problems. It is concerned with the structured process for the acquisition and application of knowledge in relation to the problems to the resolved and the solution knowledge to be applied.
The application of Design Science must be a means to an end – better solution quality – and not an end in itself – an incentive for the design function is to become large.
Solution architecture requires a (changing) combination of technical, leadership, interpersonal skills, experience, analysis, appropriate creativity, reflection and intuition applied in a structured manner.
Knowledge management – problem knowledge and solution knowledge – is at the core of the application of design science principles.
Knowledge management requires good management of the solution architecture function.
The challenge of alignment, integration and change in the development of e-services has gave attention to enterprise architecture. It provide the framework of engagement and thinking tool to define, elaborate, document, agree and communicate the strategic baseline, strategic intent, strategic architecture, strategic change and strategic resources in the development and improvement of e-services within the defined context and perspectives of time, stakeholders, performance, funds, environment, leadership and technology. The shared open presentation is a product of direct engagement with people of decision and work who are enabled to participate the formulation of enterprise architecture that matters to their performance.
The Need For Effective Early Engagement In Solution Architecture And DesignAlan McSweeney
Early engagement in the solution delivery process needs to occur before any solution delivery project is initiated. Its objective is to understand the scope, requirements, objectives, approach, options and to get a high-level understanding of the likely resources, timescale and cost required before starting the project
Fundamentally, early engagement is about managing risk:
• Risk of doing the wrong thing
• Risk of doing it in the wrong way
• Risk of underestimating complexity and scope of work
• Risk of higher than expected cost of operation and maintenance
• Risk of underestimating organisation change impact and organisation resistance
• Risk through uncertainty
Early engagement is not a requirements gathering exercise. Traditional requirements gathering requires substantial initial effort, resources and cost and for the business to commit without doubts, uncertainties and ambiguities being known.
Early Engagement involves taking a not necessarily well-defined request from the business and creating an unambiguous set of solution options including their delivery and operation quickly and accurately
This paper describes an approach to early engagement in the solution definition process.
After unnecessary complexity has been reduced from the problem being solved, the scope of the solution to the problem is governed by the complexity of the problem. Complexity is needed to handle and process complexity. Systems acquire or accrete unnecessary complexity over time as originally unforeseen exceptions or changes are incorporated. It may be possible to reduce complexity by collapsing/compressing/combining/consolidating elements and by removing non-value-adding, duplicate, redundant activities. When unnecessary or accreted complexity in the problem being solved has been removed, you are left with necessary complexity that must be incorporated into the solution. Simple problems do not have complex solutions. Complex problems do not have simple solutions. The complexity factor of the proposed solution must match the complexity factor of the problem being resolved. Many system implementation and operational failures arise because of failure to understand and address the core complexity of the problem.
Overview of the IT4IT tooling market in 2022.
Key trends in the IT4IT / DevOps tooling market are:
- Strategic portfolio management / portfolio backlog management (scaling agile on the enterprise level integrating with Enterprise architecture and Application / Product Portfolio Management)
- On-line collaboration & communication tools supporting team of team planning, problem solving, etc.
- Value stream management (an emerging tooling category) providing visibility across the end-to-end IT value streams
- Multi-cloud discovery & visibility on usage, costs and compliance
- Integrating DevOps tool chain (e.g. CICD pipeline) with the ITSM platform and CMDB
- Integrating security, risk and compliance management into the DevOps tool chain
- AIOps and observability management, consoliding metrics, logs, events mapped to a real-time service model
- Security operations, integrating security monitoring, vulnerability scanning, etc. into end-to-end detect to correct value streams
- Enterprise Service Management (ITSM vendors providing omni-channel services across IT, HR, Facilities, Finance, etc.)
- Leveraging AI/ML in various capabilities such test management, security operations, incident management, etc.
- Sustainability management integrated in IRM/GRC platforms
And last but not least:
- Service / Product portfolio management (managing the portfolio of service/applications, supporting product centric operating models, linked to business capabilities, product owners and teams)
Practical Enterprise Architecture in Medium-size Corporation using TOGAFMichael Sukachev
Overview on the Practical Enterprise Architecture approach using TOGAF ADM for architectures development, Zachman Framework as artifacts repository and Sparx EA as a modelling tool.
Solution architects must be aware of the need for solution security and of the need to have enterprise-level controls that solutions can adopt.
The sets of components that comprise the extended solution landscape, including those components that provide common or shared functionality, are located in different zones, each with different security characteristics.
The functional and operational design of any solution and therefore its security will include many of these components, including those inherited by the solution or common components used by the solution.
The complete solution security view should refer explicitly to the components and their controls.
While each individual solution should be able to inherit the security controls provided by these components, the solution design should include explicit reference to them for completeness and to avoid unvalidated assumptions.
There is a common and generalised set of components, many of which are shared, within the wider solution topology that should be considered when assessing overall solution architecture and solution security.
Individual solutions must be able to inherit security controls, facilities and standards from common enterprise-level controls, standards, toolsets and frameworks.
Individual solutions must not be forced to implement individual infrastructural security facilities and controls. This is wasteful of solution implementation resources, results in multiple non-standard approaches to security and represents a security risk to the organisation.
The extended solution landscape potentially consists of a large number of interacting components and entities located in different zones, each with different security profiles, requirements and concerns. Different security concerns and therefore controls apply to each of these components.
Solution security is not covered by a single control. It involves multiple overlapping sets of controls providing layers of security.
The latest version of the TOGAF standard has special emphasis on Business Architecture, Digital Trends, and Business Transformation beyond IT. Stuart Macgregor takes us through some of these changes to the TOGAF® 9.2 standard and discuss how they will benefit us.
Review of Information Technology Function Critical Capability ModelsAlan McSweeney
IT Function critical capabilities are key areas where the IT function needs to maintain significant levels of competence, skill and experience and practise in order to operate and deliver a service. There are several different IT capability frameworks. The objective of these notes is to assess the suitability and applicability of these frameworks. These models can be used to identify what is important for your IT function based on your current and desired/necessary activity profile.
Capabilities vary across organisation – not all capabilities have the same importance for all organisations. These frameworks do not readily accommodate variability in the relative importance of capabilities.
The assessment approach taken is to identify a generalised set of capabilities needed across the span of IT function operations, from strategy to operations and delivery. This generic model is then be used to assess individual frameworks to determine their scope and coverage and to identify gaps.
The generic IT function capability model proposed here consists of five groups or domains of major capabilities that can be organised across the span of the IT function:
1. Information Technology Strategy, Management and Governance
2. Technology and Platforms Standards Development and Management
3. Technology and Solution Consulting and Delivery
4. Operational Run The Business/Business as Usual/Service Provision
5. Change The Business/Development and Introduction of New Services
In the context of trends and initiatives such as outsourcing, transition to cloud services and greater platform-based offerings, should the IT function develop and enhance its meta-capabilities – the management of the delivery of capabilities? Is capability identification and delivery management the most important capability? Outsourced service delivery in all its forms is not a fire-and-forget activity. You can outsource the provision of any service except the management of the supply of that service.
The following IT capability models have been evaluated:
• IT4IT Reference Architecture https://www.opengroup.org/it4it contains 32 functional components
• European e-Competence Framework (ECF) http://www.ecompetences.eu/ contains 40 competencies
• ITIL V4 https://www.axelos.com/best-practice-solutions/itil has 34 management practices
• COBIT 2019 https://www.isaca.org/resources/cobit has 40 management and control processes
• APQC Process Classification Framework - https://www.apqc.org/process-performance-management/process-frameworks version 7.2.1 has 44 major IT management processes
• IT Capability Maturity Framework (IT-CMF) https://ivi.ie/critical-capabilities/ contains 37 critical capabilities
The following model has not been evaluated
• Skills Framework for the Information Age (SFIA) - http://www.sfia-online.org/ lists over 100 skills
During last few years, role of Enterprise Architecture has expanded from technical to strategic in an Organization. This slide deck presents: Using Enterprise Architecture in your Organization.
Digital Transformation And Enterprise ArchitectureAlan McSweeney
Digital transformation - extending and exposing business processes outside the organisation - by implementing a digital strategy – a statement about the organisation’s digital positioning, operating model, competitors and customer and collaborator needs and behaviour through the delivery of digital solutions defined in a digital architecture – a future state application, data and technology view to achieve digital operating status - is potentially (very) complex.
Digital architecture does not exist in isolation entirely separate from an organisation’s overall enterprise architecture. Digital architecture must exist within the within the wider enterprise architecture context.
Enterprise architecture provides the tools and the approaches to manage the complexity of digital transformation.
The management function that drives digital transformation needs to involve the enterprise architecture function in the design and implementation of digital strategy and organisation, process and policies and the creation of a digital architecture. Management must appreciate the technology focus and the benefits of an enterprise architecture approach.
The early involvement of enterprise architecture increases successes and reduces failures. Management must trust and involve enterprise architecture. The enterprise architecture function must accept and rise to the challenge and deliver. The enterprise architecture function must allow its value to be measured.
What is the Value of Mature Enterprise Architecture TOGAFxavblai
Judith Jones received the Open Group award for Outstanding Contributions to the development of TOGAF 9 at 19th Open Group Enterprise Architecture Practitioners Conference Chicago - July 21-23, 2008. Former CEO of Architecting the Enterprise which has been a member of The Open Group for 6 years, she is personnally involved since 1997. As an active member of The Open Group and she is a major contributor and an editor of TOGAF 7, 8 and 9 as well as leading TOGAF projects for localisation, case studies, ADML, synergy and collaboration projects.
http://www.opengroup.org/member/member-spotlight-jones.htm
It is well known that an effective PMO is key to successful and efficient program and project execution. In other words, doing things “right”. Enterprise Architecture is the discipline that plans and monitors enterprise transformation and aligns the business strategy with information technology capabilities. In other words, doing the “right things” to support the business.
Why is it organizations despite having both of these disciplines still struggle with effective enterprise transformation? What can we done to use these disciplines more effectively to effect better business outcomes? What are the roles of each discipline and how do they work together to create business value?
In this presentation, Riaz will address these questions and will provide real life examples that can help build a strong relationship between the PMO and Enterprise Architecture.
Learning Objectives:
• How to build a strong relationship between the PMO and Enterprise Architecture (EA) to deliver positive outcomes for your organization
• Identify the different roles and functions of the PMO and EA as well as their similarities
IT Architecture’s Role In Solving Technical Debt.pdfAlan McSweeney
Technical debt is an overworked term without an effective and common agreed understanding of what exactly it is, what causes it, what are its consequences, how to assess it and what to do about it.
Technical debt is the sum of additional direct and indirect implementation and operational costs incurred and risks and vulnerabilities created because of sub-optimal solution design and delivery decisions.
Technical debt is the sum of all the consequences of all the circumventions, budget reduction, time pressure, lack of knowledge, manual workarounds, short-cuts, avoidance, poor design and delivery quality and decisions to remove elements from solution scope and failure to provide foundational and backbone solution infrastructure.
Technical debt leads to a negative feedback cycle with short solution lifespan, earlier solution replacement and short-term tactical remedial actions.
All the disciplines within IT architecture have a role to play in promoting an understanding of and in the identification of how to resolve technical debt. IT architecture can provide the leadership in both remediating existing technical debt and preventing future debt.
Failing to take a complete view of the technical debt within the organisation means problems and risks remained unrecognised and unaddressed. The real scope of the problem is substantially underestimated. Technical debt is always much more than poorly written software.
Technical debt can introduce security risks and vulnerabilities into the organisation’s solution landscape. Failure to address technical debt leaves exploitable security risks and vulnerabilities in place.
Shadow IT or ghost IT is a largely unrecognised source of technical debt including security risks and vulnerabilities. Shadow IT is the consequence of a set of reactions by business functions to an actual or perceived inability or unwillingness of the IT function to respond to business needs for IT solutions. Shadow IT is frequently needed to make up for gaps in core business solutions, supplementing incomplete solutions and providing omitted functionality.
This examines the potential for the application of Design Science principles to the solution design process within solution architecture to improve the rigour and accuracy of solution designs.
Design Science is the structured and systematic process for creating designs that resolve problems. It is concerned with the structured process for the acquisition and application of knowledge in relation to the problems to the resolved and the solution knowledge to be applied.
The application of Design Science must be a means to an end – better solution quality – and not an end in itself – an incentive for the design function is to become large.
Solution architecture requires a (changing) combination of technical, leadership, interpersonal skills, experience, analysis, appropriate creativity, reflection and intuition applied in a structured manner.
Knowledge management – problem knowledge and solution knowledge – is at the core of the application of design science principles.
Knowledge management requires good management of the solution architecture function.
The challenge of alignment, integration and change in the development of e-services has gave attention to enterprise architecture. It provide the framework of engagement and thinking tool to define, elaborate, document, agree and communicate the strategic baseline, strategic intent, strategic architecture, strategic change and strategic resources in the development and improvement of e-services within the defined context and perspectives of time, stakeholders, performance, funds, environment, leadership and technology. The shared open presentation is a product of direct engagement with people of decision and work who are enabled to participate the formulation of enterprise architecture that matters to their performance.
The Need For Effective Early Engagement In Solution Architecture And DesignAlan McSweeney
Early engagement in the solution delivery process needs to occur before any solution delivery project is initiated. Its objective is to understand the scope, requirements, objectives, approach, options and to get a high-level understanding of the likely resources, timescale and cost required before starting the project
Fundamentally, early engagement is about managing risk:
• Risk of doing the wrong thing
• Risk of doing it in the wrong way
• Risk of underestimating complexity and scope of work
• Risk of higher than expected cost of operation and maintenance
• Risk of underestimating organisation change impact and organisation resistance
• Risk through uncertainty
Early engagement is not a requirements gathering exercise. Traditional requirements gathering requires substantial initial effort, resources and cost and for the business to commit without doubts, uncertainties and ambiguities being known.
Early Engagement involves taking a not necessarily well-defined request from the business and creating an unambiguous set of solution options including their delivery and operation quickly and accurately
This paper describes an approach to early engagement in the solution definition process.
After unnecessary complexity has been reduced from the problem being solved, the scope of the solution to the problem is governed by the complexity of the problem. Complexity is needed to handle and process complexity. Systems acquire or accrete unnecessary complexity over time as originally unforeseen exceptions or changes are incorporated. It may be possible to reduce complexity by collapsing/compressing/combining/consolidating elements and by removing non-value-adding, duplicate, redundant activities. When unnecessary or accreted complexity in the problem being solved has been removed, you are left with necessary complexity that must be incorporated into the solution. Simple problems do not have complex solutions. Complex problems do not have simple solutions. The complexity factor of the proposed solution must match the complexity factor of the problem being resolved. Many system implementation and operational failures arise because of failure to understand and address the core complexity of the problem.
Overview of the IT4IT tooling market in 2022.
Key trends in the IT4IT / DevOps tooling market are:
- Strategic portfolio management / portfolio backlog management (scaling agile on the enterprise level integrating with Enterprise architecture and Application / Product Portfolio Management)
- On-line collaboration & communication tools supporting team of team planning, problem solving, etc.
- Value stream management (an emerging tooling category) providing visibility across the end-to-end IT value streams
- Multi-cloud discovery & visibility on usage, costs and compliance
- Integrating DevOps tool chain (e.g. CICD pipeline) with the ITSM platform and CMDB
- Integrating security, risk and compliance management into the DevOps tool chain
- AIOps and observability management, consoliding metrics, logs, events mapped to a real-time service model
- Security operations, integrating security monitoring, vulnerability scanning, etc. into end-to-end detect to correct value streams
- Enterprise Service Management (ITSM vendors providing omni-channel services across IT, HR, Facilities, Finance, etc.)
- Leveraging AI/ML in various capabilities such test management, security operations, incident management, etc.
- Sustainability management integrated in IRM/GRC platforms
And last but not least:
- Service / Product portfolio management (managing the portfolio of service/applications, supporting product centric operating models, linked to business capabilities, product owners and teams)
Practical Enterprise Architecture in Medium-size Corporation using TOGAFMichael Sukachev
Overview on the Practical Enterprise Architecture approach using TOGAF ADM for architectures development, Zachman Framework as artifacts repository and Sparx EA as a modelling tool.
Solution architects must be aware of the need for solution security and of the need to have enterprise-level controls that solutions can adopt.
The sets of components that comprise the extended solution landscape, including those components that provide common or shared functionality, are located in different zones, each with different security characteristics.
The functional and operational design of any solution and therefore its security will include many of these components, including those inherited by the solution or common components used by the solution.
The complete solution security view should refer explicitly to the components and their controls.
While each individual solution should be able to inherit the security controls provided by these components, the solution design should include explicit reference to them for completeness and to avoid unvalidated assumptions.
There is a common and generalised set of components, many of which are shared, within the wider solution topology that should be considered when assessing overall solution architecture and solution security.
Individual solutions must be able to inherit security controls, facilities and standards from common enterprise-level controls, standards, toolsets and frameworks.
Individual solutions must not be forced to implement individual infrastructural security facilities and controls. This is wasteful of solution implementation resources, results in multiple non-standard approaches to security and represents a security risk to the organisation.
The extended solution landscape potentially consists of a large number of interacting components and entities located in different zones, each with different security profiles, requirements and concerns. Different security concerns and therefore controls apply to each of these components.
Solution security is not covered by a single control. It involves multiple overlapping sets of controls providing layers of security.
This is the deck of a webinar that I presented at the OpenGroup. The focus of this webinar is on the challenge of using these standards in practice to build a strong architecture capability in organizations.
What Can We Do With The ArchiMate Language?Iver Band
Last year, the Open Group released version 3.0 of the ArchiMate® standard, which provides a language with concepts for describing enterprise and solution architectures, a framework for organizing these concepts, a graphical notation for these concepts, and recommendations for viewpoints, which are visualization templates that address the concerns of particular stakeholders. The standard is public and free for end users. It can be extended through specialization of its concepts and relationships, and is supported by an increasing number of tools, consultancies and training organizations.
We use a fictitious—but realistic—case study to describe what we can do with the ArchiMate language. Each of the sections in this article presents one or more views of an ArchiMate model that tells a story about the collection and analysis of Big Data to create business value. Big Data consists of datasets that cannot be handled efficiently with traditional centralized data architectures due to their extensive volume, variety, velocity and variability. These characteristics demand scalable architectures for efficient storage, manipulation and analysis.
Visual Paradigm enables your team to manage enterprise transformation complexity for coping with the rapidly-changing markets, technologies, and regulatory requirements. It is an ideal one-stop-shop solution for enterprise architecture planning and business transformation, project management and agile software development, so that your company can stay in control and foster growth.
Enterprise Architecture - An Introduction from the Real World Daljit Banger
The attached slides where presented at a BCS EA SIG organised event hosted by Deloitte in Edinburgh on the 24th April 2017.
Slide 7 is not rendered as I wish to protect the IP, however will publish soon
When a company invests in ITIL, very often Architecture is not much involved: this is a mistake because there is much overlap, and Architecture can end up side-lined by the ITIL juggernaut. But there are a lot of benefits Architecture can bring to an ITIL-oriented organization.
This slide deck goes a step or two further than the white-papers out there I've found to date in providing some concrete guidance on how to actually integrate Architecture activities into ITIL. The deck uses TOGAF as the reference framework, but the concepts can be applied to any modern Architecture practice, since the discussion focuses on the types of deliverables and activities, which analogously exist in most frameworks.
ArchiMate 3.0: A New Standard for ArchitectureIver Band
This keynote presentation from the July 2016 Open Group Austin Conference introduces the new version of the ArchiMate standard. ArchiMate 3.0 extends the language with various concepts that help enterprise architects tackle challenges in digital transformation and business change. This major new version introduces explicit support for capability-based planning, and improves linkage between business strategy and all architecture layers. ArchiMate 3.0 also enables modelers to describe the Internet of Things and the systems of the physical world, such as manufacturing and logistics. In addition, the new version supports more compact and intuitive visual models. This presentation includes examples that use these improvements and demonstrates how architects can benefit from them.
An introduction to fundamental architecture conceptswweinmeyer79
(Note: This is a very dated version of this popular deck, as SlideShare does not provide authors with a mechanism to update their documents. If interested in the latest version, feel free to message me on LinkedIn or at wweinmeyer@gmail.com. Also, feel free to ask SlideShare to bring back the ability to update posted documents.)
A discussion of the fundamentals you need to nail in your architecture practice:
- Architecture vs. Design
- Conceptual vs. Logical vs. Physical architecture
- Viewpoint Frameworks
- Architecture Domains
- Architecture Tiers
You are free to use/copy this information but if you do so, please include an acknowledgement
An Introduction to Enterprise Architecture Visual Modeling With The ArchiMate...Iver Band
A half-day introduction to the ArchiMate language, including core concepts, a visual Overview, and a case study. Introduces the entire language, including the Business, Application and Technology layers as well as the Motivation and implementation and Migration extensions. Ideal for enterprise and solution architects and other architecture contributors.
The case study uses the free Archi tool, and includes download instructions. Those interested in learning the language can attempt each case study exercise using Archi, and flip to the next slide to check their work.
Incorporating A DesignOps Approach Into Solution ArchitectureAlan McSweeney
Solution architecture and design is concerned with designing new (IT) solutions to resolve problems or address opportunities . In order to solve a problem, you need sufficient information to understand the problem. If you do not understand the scope of the required solution you cannot understand the risks associated with the implementation approach.
Getting the solution wrong can be very expensive. The DesignOps approach is a unified end-to-end view of solution delivery from initial concept to steady state operations. It is a design-to-operations approach identifying all the solution design elements needed to ensure the delivery of a complete solution.
Solution architecture and design teams are becoming larger so more co-ordination, standardisation and management is required. The increasing focus on digital transformation increases the need for improved design as business applications are exposed outside the organisation. Solution complexity is increasing. The aim of the DesignOps approach is to improve solution design outcomes.
A comprehensive methodology for the design, implementation and deployment of PLM solutions. The approach is based on insights and lessons learned from over 100 PLM implementations and 10 years of experience.
Comprehensive And Integrated Approach To Project Management And Solution Deli...Alan McSweeney
Describes a complete and integrated approach to solution delivery that encompasses project management, project portfolio management, business analysis and solution architecture and design
Effective solution delivery requires an integrated approach to projects across all key disciplines
Project portfolio management
Project management
Business analysis
Solution design
Having silos of expertise that do not communicate or co-operate leads to significant risk
This presentation describes systematic, repeatable and co-ordinated approach to agile solution architecture and design. It is intended to describe a set of practical steps and activities embedded within a framework to allow an agile method to be adopted and used for solution design and delivery. This approach ensures consistency in the assessment of solution design options and in subsequent solution design and solution delivery activities. This process leads to the rapid design and delivery of realistic and achievable solutions that meet real solution consumer needs. The approach provides for effective solution decision-making. It generates options and results quickly and consistently. Implementing a framework such as this provides for the creation of a knowledgebase of previous solution design and delivery exercises that leads to an accumulated body of knowledge within the organisation.
Solution Architecture And User And Customer ExperienceAlan McSweeney
User experience is the sum of experiences across all dimensions of all solutions and the user’s interaction with it including its functionality and quality attributes. It is the sum of all interactions with the solution and the results the solution provides. Solution usability is much, much more than a user interface
Users experience the complete operational solution across its entire scope and experience its functional and quality properties. The solution architect must be aware of the usability of designed solutions. Usability is not an afterthought: it must be embedded in the overall solution design from the start
The dimensions of solution usability are:
• Components of overall solution
• Functional components of solution
• Quality properties
The complete solution Is always much more than just a bunch of software. Implementing the end-to-end components of the solution positively impacts on solution usability and utility. Without the complete view there will be gaps in the usability of the solution.
Enterprise architecture needs to provide leadership in defining and implementing approach to measuring solution usability. Enterprise architecture needs to define standards and associated frameworks for
• Overall experience
• Solution usability
Each of these needs to include measurement and analysis framework. Solution architecture needs to incorporate these standards into solution designs. Individual solutions incorporate usability standards
Overall set of solutions comprise the experience.
This deck provides a high-level framework to implement business process redesign within a business transformation initiative. It shows how to establish the team, define the approach, and identify some of the deliverables within this track of work.
Every organization needs to adapt to the ever-changing business environment. Sensing this need, we have come up with these content-ready change management PowerPoint presentation slides. These change management PPT templates will help you deal with any kind of an organizational change. Be it with people, goals or processes. The business solutions incorporated here will help you identify the organizational structure, create vision for change, implement strategies, identify resistance and risk, manage cost of change, get feedback and evaluation, and much more. With the help of various change management tools and techniques illustrated in this presentation design, you can achieve the desired business outcomes. This business transition PowerPoint design also covers certain related topics such as change model, transformation strategy, change readiness, change control, project management and business process. By implementing the change control methods mentioned in the presentation, you will be able to have a smooth transition in an organization. So, without waiting much, download our extensively researched change management framework presentation. With our Change Management Presentation slides, understand the need for change and plan to go through it without any hassles.
NVISIA shares key insight for building enterprise mobile applications by connecting business units with IT, using the 10x Leadership Disciplines as defined in the book Good to Great.
Describes a multi-dimensional view of the Business Analysis Body of Knowledge, based upon artifacts and their consumers.
The BABOK is captured with a UML model that shows how activities, artifacts, roles and techniques are related. I created this model to help study for the CBAP exam.
Demystifying SharePoint Governance and User AdoptionWes Preston
Governance and User Adoption continue to be hot topics in the SharePoint community and are still adapting as the community matures. So, what do these buzzwords mean to you and your organization? In this session we'll explain what they mean, why they shouldn't be something to fear or over-think, and how to approach these topics as a part of your SharePoint planning, implementations and ongoing management.
The data architecture of solutions is frequently not given the attention it deserves or needs. Frequently, too little attention is paid to designing and specifying the data architecture within individual solutions and their constituent components. This is due to the behaviours of both solution architects ad data architects.
Solution architecture tends to concern itself with functional, technology and software components of the solution
Data architecture tends not to get involved with the data aspects of technology solutions, leaving a data architecture gap. Combined with the gap where data architecture tends not to get involved with the data aspects of technology solutions, there is also frequently a solution architecture data gap. Solution architecture also frequently omits the detail of data aspects of solutions leading to a solution data architecture gap. These gaps result in a data blind spot for the organisation.
Data architecture tends to concern itself with post-individual solutions. Data architecture needs to shift left into the domain of solutions and their data and more actively engage with the data dimensions of individual solutions. Data architecture can provide the lead in sealing these data gaps through a shift-left of its scope and activities as well providing standards and common data tooling for solution data architecture
The objective of data design for solutions is the same as that for overall solution design:
• To capture sufficient information to enable the solution design to be implemented
• To unambiguously define the data requirements of the solution and to confirm and agree those requirements with the target solution consumers
• To ensure that the implemented solution meets the requirements of the solution consumers and that no deviations have taken place during the solution implementation journey
Solution data architecture avoids problems with solution operation and use:
• Poor and inconsistent data quality
• Poor performance, throughput, response times and scalability
• Poorly designed data structures can lead to long data update times leading to long response times, affecting solution usability, loss of productivity and transaction abandonment
• Poor reporting and analysis
• Poor data integration
• Poor solution serviceability and maintainability
• Manual workarounds for data integration, data extract for reporting and analysis
Data-design-related solution problems frequently become evident and manifest themselves only after the solution goes live. The benefits of solution data architecture are not always evident initially.
Solution Architecture and Solution Estimation.pdfAlan McSweeney
Solution architects and the solution architecture function are ideally placed to create solution delivery estimates
Solution architects have the knowledge and understanding of the solution constituent component and structure that is needed to create solution estimate:
• Knowledge of solution options
• Knowledge of solution component structure to define a solution breakdown structure
• Knowledge of available components and the options for reuse
• Knowledge of specific solution delivery constraints and standards that both control and restrain solution options
Accurate solution delivery estimates are need to understand the likely cost/resources/time/options needed to implement a new solution within the context of a range of solutions and solution options. These estimates are a key input to investment management and making effective decisions on the portfolio of solutions to implement. They enable informed decision-making as part of IT investment management.
An estimate is not a single value. It is a range of values depending on a number of conditional factors such level of knowledge, certainty, complexity and risk. The range will narrow as the level of knowledge and uncertainty decreases
There is no easy or magic way to create solution estimates. You have to engage with the complexity of the solution and its components. The more effort that is expended the more accurate the results of the estimation process will be. But there is always a need to create estimates (reasonably) quickly so a balance is needed between effort and quality of results.
The notes describe a structured solution estimation process and an associated template. They also describe the wider context of solution estimates in terms of IT investment and value management and control.
Validating COVID-19 Mortality Data and Deaths for Ireland March 2020 – March ...Alan McSweeney
This analysis seeks to validate published COVID-19 mortality statistics using mortality data derived from general mortality statistics, mortality estimated from population size and mortality rates and death notice data
Analysis of the Numbers of Catholic Clergy and Members of Religious in Irelan...Alan McSweeney
This analysis looks at the changes in the numbers of priests and nuns in Ireland for the years 1926 to 2016. It combines data from a range of sources to show the decline in the numbers of priests and nuns and their increasing age profile.
This analysis consists of the following sections:
• Summary - this highlights some of the salient points in the analysis.
• Overview of Analysis - this describes the approach taken in this analysis.
• Context – this provides background information on the number of Catholics in Ireland as a context to this analysis.
• Analysis of Census Data 1926 – 2016 - this analyses occupation age profile data for priests and nuns. It also includes sample projections on the numbers of priests and nuns.
• Analysis of Catholic Religious Mortality 2014-2021 - this analyses death notice data from RIP.ie to shows the numbers of priests and nuns that have died in the years 2014 to 2021. It also looks at deaths of Irish priests and nuns outside Ireland and at the numbers of countries where Irish priests and nuns have worked.
• Analysis of Data on Catholic Clergy From Other Sources - this analyses data on priests and nuns from other sources.
• Notes on Data Sources and Data Processing - this lists the data sources used in this analysis.
Solution Architecture And Solution SecurityAlan McSweeney
This describes an approach to embedding security within the technology solution landscape. It describes a security model that encompasses the range of individual solution components up to the entire solution landscape. The solution security model allows the security status of a solution and its constituent delivery and operational components to be tracked wherever those components are located. This provides an integrated approach to solution security across all solution components and across the entire organisation topology of solutions. It allows the solution architect to validate the security of an individual solution. It enables the security status of the entire solution landscape to be assessed and recorded. Solution security is a wicked problem because there is no certainly about when the problem has been resolved and a state of security has been achieved. The security state of a solution can just be expressed along a subjective spectrum of better or worse rather than a binary true or false. Solution security can have negative consequences: prevents types of access, limits availability in different ways, restricts functionality provided, makes solution harder to use, lengthens solution delivery times, increases costs along the entire solution lifecycle, leads to loss of usability, utility and rate of use.
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...Alan McSweeney
This paper describes how technologies such as data pseudonymisation and differential privacy technology enables access to sensitive data and unlocks data opportunities and value while ensuring compliance with data privacy legislation and regulations.
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...Alan McSweeney
Your data has value to your organisation and to relevant data sharing partners. It has been expensively obtained. It represents a valuable asset on which a return must be generated. To achieve the value inherent in the data you need to be able to make it appropriately available to others, both within and outside the organisation.
Organisations are frequently data rich and information poor, lacking the skills, experience and resources to convert raw data into value.
These notes outline technology approaches to achieving compliance with data privacy regulations and legislation while providing access to data.
There are different routes to making data accessible and shareable within and outside the organisation without compromising compliance with data protection legislation and regulations and removing the risk associated with allowing access to personal data:
• Differential Privacy – source data is summarised and individual personal references are removed. The one-to-one correspondence between original and transformed data has been removed
• Anonymisation – identifying data is destroyed and cannot be recovered so individual cannot be identified. There is still a one-to-one correspondence between original and transformed data
• Pseudonymisation – identifying data is encrypted and recovery data/token is stored securely elsewhere. There is still a one-to-one correspondence between original and transformed data
These technologies and approaches are not mutually exclusive – each is appropriate to differing data sharing and data access use cases
The data privacy regulatory and legislative landscape is complex and getting even more complex so an approach to data access and sharing that embeds compliance as a matter of course is required.
Appropriate technology appropriately implemented and operated is a means of managing and reducing risks of re-identification by making the time, skills, resources and money necessary to achieve this unrealistic.
Technology is part of a risk management approach to data privacy. There is wider operational data sharing and data privacy framework that includes technology aspects, among other key areas. Using these technologies will embed such compliance by design into your data sharing and access facilities. This will allow you to realise value from your data successfully.
Solution Architecture And (Robotic) Process Automation SolutionsAlan McSweeney
Automation is a technology trend IT architects should be aware of and know how to respond to business requests as well as recommend automation technologies and solutions where appropriate. Automation is a bigger topic than just RPA (Robotic Process Automation).
Automation solutions, like all other technology solutions, should be subject to an architecture and design process. There are many approaches to and options for the automation of business activities. Too often automation solutions are tactical applications layered over existing business systems
The objective of all IT solutions is to automate manual business processes and their activities to a certain extent. The requirement for RPA-type applications arises in part because of automation failures within existing applications or the need to automate the interactions with or integrations between separate, possibly legacy, applications.
One of the roles of IT architecture is to always seek to take the wider architectural view and to ensure that solutions are designed and delivered within a strategic framework to avoid, as much as is practical and realistic, short-term tactical solutions and approaches that lead to an accumulation of design, operations and support debt. Tactical solutions will always play a part in the organisation’s solution landscape.
The objective of these notes is to put automation into its wider and larger IT architecture context while accepting the need for tactical approaches in some instances.
These notes cover the following topics:
• Solution And Process Automation – The Wider Technology And Approach Landscape
• Business Processes, Business Solutions And Automation
• Organisation Process Model
• Strategic And Tactical Automation
• Deciding On The Scope Of Automation
• Digital Strategy, Digital Transformation And Automation
• Specifying The Automation Solution
• Business Process Model and Notation (BPMN)
• Sample Business Process – Order To Cash
• RPA (Robotic Process Automation)
Data Profiling, Data Catalogs and Metadata HarmonisationAlan McSweeney
These notes discuss the related topics of Data Profiling, Data Catalogs and Metadata Harmonisation. It describes a detailed structure for data profiling activities. It identifies various open source and commercial tools and data profiling algorithms. Data profiling is a necessary pre-requisite activity in order to construct a data catalog. A data catalog makes an organisation’s data more discoverable. The data collected during data profiling forms the metadata contained in the data catalog. This assists with ensuring data quality. It is also a necessary activity for Master Data Management initiatives. These notes describe a metadata structure and provide details on metadata standards and sources.
Comparison of COVID-19 Mortality Data and Deaths for Ireland March 2020 – Mar...Alan McSweeney
This document compares published COVID-19 mortality statistics for Ireland with publicly available mortality data extracted from informal public data sources. This mortality data is taken from published death notices on the web site www.rip.ie. This is used a substitute for poor quality and long-delayed officially published mortality statistics.
Death notice information on the web site www.rip.ie is available immediately and contains information at a greater level of detail than published statistics. There is a substantial lag in officially published mortality data and the level of detail is very low. However, the extraction of death notice data and its conversion into a usable and accurate format requires a great deal of processing.
The objective of this analysis is to assess the accuracy of published COVID-19 mortality statistics by comparing trends in mortality over the years 2014 to 2020 with both numbers of deaths recorded from 2020 to 2021 and the COVID-19 statistics. It compares number of deaths for the seven 13-month intervals:
1. Mar 2014 - Mar 2015
2. Mar 2015 - Mar 2016
3. Mar 2016 - Mar 2017
4. Mar 2017 - Mar 2018
5. Mar 2018 - Mar 2019
6. Mar 2019 - Mar 2020
7. Mar 2020 - Mar 2021
It focuses on the seventh interval which is when COVID-19 deaths have occurred. It combines an analysis of mortality trends with details on COVID-19 deaths. This is a fairly simplistic analysis that looks to cross-check COVID-19 death statistics using data from other sources.
The subject of what constitutes a death from COVID-19 is controversial. This analysis is not concerned with addressing this controversy. It is concerned with comparing mortality data from a number of sources to identify potential discrepancies. It may be the case that while the total apparent excess number of deaths over an interval is less than the published number of COVID-19 deaths, the consequence of COVID-19 is to accelerate deaths that might have occurred later in the measurement interval.
Accurate data is needed to make informed decisions. Clearly there are issues with Irish COVID-19 mortality data. Accurate data is also needed to ensure public confidence in decision-making. Where this published data is inaccurate, this can lead of a loss of this confidence that can exploited.
Analysis of Decentralised, Distributed Decision-Making For Optimising Domesti...Alan McSweeney
This analysis looks at the potential impact that large numbers of electric vehicles could have on electricity demand, electricity generation capacity and on the electricity transmission and distribution grid in Ireland. It combines data from a number of sources – electricity usage patterns, vehicle usage patterns, electric vehicle current and possible future market share – to assess the potential impact of electric vehicles.
It then analyses a possible approach to electric vehicle charging where the domestic charging unit has some degree of decentralised intelligence and decision-making capability in deciding when to start vehicle charging to minimise electricity usage impact and optimise electricity generation usage.
The potential problem to be addressed is that if large numbers of electric cars are plugged-in and charging starts immediately when the drivers of those cars arrive home, the impact on demand for electricity will be substantial.
Operational Risk Management Data Validation ArchitectureAlan McSweeney
This describes a structured approach to validating data used to construct and use an operational risk model. It details an integrated approach to operational risk data involving three components:
1. Using the Open Group FAIR (Factor Analysis of Information Risk) risk taxonomy to create a risk data model that reflects the required data needed to assess operational risk
2. Using the DMBOK model to define a risk data capability framework to assess the quality and accuracy of risk data
3. Applying standard fault analysis approaches - Fault Tree Analysis (FTA) and Failure Mode and Effect Analysis (FMEA) - to the risk data capability framework to understand the possible causes of risk data failures within the risk model definition, operation and use
Data Integration, Access, Flow, Exchange, Transfer, Load And Extract Architec...Alan McSweeney
These notes describe a generalised data integration architecture framework and set of capabilities.
With many organisations, data integration tends to have evolved over time with many solution-specific tactical approaches implemented. The consequence of this is that there is frequently a mixed, inconsistent data integration topography. Data integrations are often poorly understood, undocumented and difficult to support, maintain and enhance.
Data interoperability and solution interoperability are closely related – you cannot have effective solution interoperability without data interoperability.
Data integration has multiple meanings and multiple ways of being used such as:
- Integration in terms of handling data transfers, exchanges, requests for information using a variety of information movement technologies
- Integration in terms of migrating data from a source to a target system and/or loading data into a target system
- Integration in terms of aggregating data from multiple sources and creating one source, with possibly date and time dimensions added to the integrated data, for reporting and analytics
- Integration in terms of synchronising two data sources or regularly extracting data from one data sources to update a target
- Integration in terms of service orientation and API management to provide access to raw data or the results of processing
There are two aspects to data integration:
1. Operational Integration – allow data to move from one operational system and its data store to another
2. Analytic Integration – move data from operational systems and their data stores into a common structure for analysis
Ireland 2019 and 2020 Compared - Individual ChartsAlan McSweeney
This analysis compares some data areas - Economy, Crime, Aviation, Energy, Transport, Health, Mortality. Housing and Construction - for Ireland for the years 2019 and 2020, illustrating the changes that have occurred between the two years. It shows some of the impacts of COVID-19 and of actions taken in response to it, such as the various lockdowns and other restrictions.
The first lockdown clearly had major changes on many aspects of Irish society. The third lockdown which began at the end of the period analysed will have as great an impact as the first lockdown.
The consequences of the events and actions that have causes these impacts could be felt for some time into the future.
Analysis of Irish Mortality Using Public Data Sources 2014-2020Alan McSweeney
This describes the use of published death notices on the web site www.rip.ie as a substitute to officially published mortality statistics. This analysis uses data from RIP.ie for the years 2014 to 2020.
Death notice information is available immediately and contains information at a greater level of detail than published statistics. There is a substantial lag in officially published mortality data.
This analysis compares some data areas - Economy, Crime, Aviation, Energy, Transport, Health, Mortality. Housing and Construction - for Ireland for the years 2019 and 2020, illustrating the changes that have occurred between the two years. It shows some of the impacts of COVID-19 and of actions taken in response to it, such as the various lockdowns and other restrictions.
The first lockdown clearly had major changes on many aspects of Irish society. The third lockdown which began at the end of the period analysed will have as great an impact as the first lockdown.
The consequences of the events and actions that have causes these impacts could be felt for some time into the future.
Critical Review of Open Group IT4IT Reference ArchitectureAlan McSweeney
This reviews the Open Group’s IT4IT Reference Architecture (https://www.opengroup.org/it4it) with respect to other operational frameworks to determine its suitability and applicability to the IT operating function.
IT4IT is intended to be a reference architecture for the management of the IT function. It aims to take a value chain approach to create a model of the functions that IT performs and the services it provides to assist organisations in the identification of the activities that contribute to business competitiveness. It is intended to be an integrated framework for the management of IT that emphasises IT service lifecycles.
This paper reviews what is meant by a value-chain, with special reference to the Supply Chain Operations Reference (SCOR) model (https://www.apics.org/apics-for-business/frameworks/scor). the most widely used and most comprehensive such model.
The SCOR model is part of wider set of operations reference models that describe a view of the critical elements in a value chain:
• Product Life Cycle Operations Reference model (PLCOR) - Manages the activities for product innovation and product and portfolio management
• Customer Chain Operations Reference model (CCOR) - Manages the customer interaction processes
• Design Chain Operations Reference model (DCOR) - Manages the product and service development processes
• Managing for Supply Chain Performance (M4SC) - Translates business strategies into supply chain execution plans and policies
It also compares the IT4IT Reference Architecture and its 32 functional components to other frameworks that purport to identify the critical capabilities of the IT function:
• IT Capability Maturity Framework (IT-CMF) https://ivi.ie/critical-capabilities/ contains 37 critical capabilities
• Skills Framework for the Information Age (SFIA) - http://www.sfia-online.org/ lists over 100 skills
• European e-Competence Framework (ECF) http://www.ecompetences.eu/ contains 40 competencies
• ITIL IT Service Management https://www.axelos.com/best-practice-solutions/itil
• COBIT 2019 https://www.isaca.org/resources/cobit has 40 management and control processes
Analysis of Possible Excess COVID-19 Deaths in Ireland From Jan 2020 to Jun 2020Alan McSweeney
This analysis seeks to determine if there are excess deaths that occurred in Ireland in the interval Jan – Jun 2020 that can be attributed to COVID-19. Excess deaths means deaths in excess of the number of expected deaths plus the number of deaths directly attributed to COVID-19. On the other hand a deficiency of deaths would occur when the number of expected deaths plus the number of deaths directly attributed to COVID-19 is less than the actual deaths.
This analysis uses number of deaths taken from the web site RIP.ie to generate an estimate of the number of deaths in Jan – Jun 2020 in the absence of any other official source. The last data extract from the RIP.ie web site was taken on 3 Jul 2020.
The analysis uses historical data from RIP.ie from 2018 and 2019 to assess its accuracy as a data source.
The analysis then uses the following three estimation approaches to assess the excess or deficiency of deaths:
1. The pattern of deaths in 2020 can be compared to previous comparable year or years. The additional COVID-19 deaths can be added to the comparable year and the difference between the expected, actual from RIP.ie and actual COVID-19 deaths can be analysed to generate an estimate of any excess or deficiency.
2. The age-specific mortality rates described on page 16 can be applied to estimates of population numbers to generates an estimate of expected deaths. This can be compared to the actual RIP.ie and actual COVID-19 deaths to generate an estimate of any excess or deficiency.
3. The range of death rates per 1,000 of population as described in Figure 10 on page 16 can be applied to estimates of population numbers to generates an estimate of expected deaths. This can be compared to the actual RIP.ie and actual COVID-19 deaths to generate an estimate of any excess or deficiency.
Solution Architecture and Solution AcquisitionAlan McSweeney
This describes a systematised and structured approach to solution acquisition or procurement that involves solution architecture from the start. This allows the true scope of both the required and subsequently acquired solution are therefore fully understood. By using such an approach, poor solution acquisition outcomes are avoided.
Solution architecture provides the structured approach to capturing all the cost contributors and knowing the true solution scope.
There is more packaged/product/service-based solution acquisition activity. There is an increasing trend of solutions hosted outside the organisation. Meanwhile solution acquisition outcomes are poor and getting worse.
Poor solution acquisition has long-term consequences and costs.
The to-be-acquired solution needs to operate in and co-exist with an existing solution topography and the solution acquisition process needs to be aware of and take account of this wider solution topography. Cloud-based or externally hosted and provided solutions do not eliminate the need for the solution to exist within the organisation solution topography.
Strategic misrepresentation in solution acquisition is the deliberate distortion or falsification of information relating to solution acquisition costs, complexity, required functionality, solution availability, resource availability, time to implement in order to get solution acquisition approval. Strategic misrepresentation is very real and its consequences can be very damaging.
Solution architecture has the skills and experience to define the real scope of the solution being acquired. An effective structured solution acquisition process, well-implemented and consistently applied, means dependable and repeatable solution acquisition and successful outcomes.
Creating A Business Focussed Information Technology StrategyAlan McSweeney
This presentation describes a structured approach to creating a business-focussed information technology strategy.
An effective business-oriented IT strategy is an opportunity to resolve the disconnection and to ensure the IT function is able to and does respond to business needs and is trusted by the business to provide IT solutions.
The IT strategy will consist of static structural elements relating to the organisation of the IT function:
• Capabilities – skills and abilities the IT function should possess and be able to use effectively and efficiently
• IT Function Structure – the organisation and arrangement of the sub-functions and their responsibilities and relationships
• Operating Model – how the IT function work and delivers value and the processes it implements and operates
• Staffing And Roles – the numbers of people, their roles, responsibilities, expected skills, experience and abilities, workload, reporting structures and expected ways of operating
It will also include dynamic elements relating to initiatives, both enabling initiatives within the IT function and specific business initiatives required to achieve the business strategy.
UiPath Test Automation using UiPath Test Suite series, part 5DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 5. In this session, we will cover CI/CD with devops.
Topics covered:
CI/CD with in UiPath
End-to-end overview of CI/CD pipeline with Azure devops
Speaker:
Lyndsey Byblow, Test Suite Sales Engineer @ UiPath, Inc.
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Elevating Tactical DDD Patterns Through Object CalisthenicsDorra BARTAGUIZ
After immersing yourself in the blue book and its red counterpart, attending DDD-focused conferences, and applying tactical patterns, you're left with a crucial question: How do I ensure my design is effective? Tactical patterns within Domain-Driven Design (DDD) serve as guiding principles for creating clear and manageable domain models. However, achieving success with these patterns requires additional guidance. Interestingly, we've observed that a set of constraints initially designed for training purposes remarkably aligns with effective pattern implementation, offering a more ‘mechanical’ approach. Let's explore together how Object Calisthenics can elevate the design of your tactical DDD patterns, offering concrete help for those venturing into DDD for the first time!
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
Observability Concepts EVERY Developer Should Know -- DeveloperWeek Europe.pdfPaige Cruz
Monitoring and observability aren’t traditionally found in software curriculums and many of us cobble this knowledge together from whatever vendor or ecosystem we were first introduced to and whatever is a part of your current company’s observability stack.
While the dev and ops silo continues to crumble….many organizations still relegate monitoring & observability as the purview of ops, infra and SRE teams. This is a mistake - achieving a highly observable system requires collaboration up and down the stack.
I, a former op, would like to extend an invitation to all application developers to join the observability party will share these foundational concepts to build on:
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
GraphRAG is All You need? LLM & Knowledge GraphGuy Korland
Guy Korland, CEO and Co-founder of FalkorDB, will review two articles on the integration of language models with knowledge graphs.
1. Unifying Large Language Models and Knowledge Graphs: A Roadmap.
https://arxiv.org/abs/2306.08302
2. Microsoft Research's GraphRAG paper and a review paper on various uses of knowledge graphs:
https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
GraphSummit Singapore | The Art of the Possible with Graph - Q2 2024Neo4j
Neha Bajwa, Vice President of Product Marketing, Neo4j
Join us as we explore breakthrough innovations enabled by interconnected data and AI. Discover firsthand how organizations use relationships in data to uncover contextual insights and solve our most pressing challenges – from optimizing supply chains, detecting fraud, and improving customer experiences to accelerating drug discoveries.
SAP Sapphire 2024 - ASUG301 building better apps with SAP Fiori.pdfPeter Spielvogel
Building better applications for business users with SAP Fiori.
• What is SAP Fiori and why it matters to you
• How a better user experience drives measurable business benefits
• How to get started with SAP Fiori today
• How SAP Fiori elements accelerates application development
• How SAP Build Code includes SAP Fiori tools and other generative artificial intelligence capabilities
• How SAP Fiori paves the way for using AI in SAP apps
Essentials of Automations: The Art of Triggers and Actions in FMESafe Software
In this second installment of our Essentials of Automations webinar series, we’ll explore the landscape of triggers and actions, guiding you through the nuances of authoring and adapting workspaces for seamless automations. Gain an understanding of the full spectrum of triggers and actions available in FME, empowering you to enhance your workspaces for efficient automation.
We’ll kick things off by showcasing the most commonly used event-based triggers, introducing you to various automation workflows like manual triggers, schedules, directory watchers, and more. Plus, see how these elements play out in real scenarios.
Whether you’re tweaking your current setup or building from the ground up, this session will arm you with the tools and insights needed to transform your FME usage into a powerhouse of productivity. Join us to discover effective strategies that simplify complex processes, enhancing your productivity and transforming your data management practices with FME. Let’s turn complexity into clarity and make your workspaces work wonders!
Unlocking Productivity: Leveraging the Potential of Copilot in Microsoft 365, a presentation by Christoforos Vlachos, Senior Solutions Manager – Modern Workplace, Uni Systems
Threats to mobile devices are more prevalent and increasing in scope and complexity. Users of mobile devices desire to take full advantage of the features
available on those devices, but many of the features provide convenience and capability but sacrifice security. This best practices guide outlines steps the users can take to better protect personal devices and information.
Alt. GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using ...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Communications Mining Series - Zero to Hero - Session 1DianaGray10
This session provides introduction to UiPath Communication Mining, importance and platform overview. You will acquire a good understand of the phases in Communication Mining as we go over the platform with you. Topics covered:
• Communication Mining Overview
• Why is it important?
• How can it help today’s business and the benefits
• Phases in Communication Mining
• Demo on Platform overview
• Q/A
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
GridMate - End to end testing is a critical piece to ensure quality and avoid...ThomasParaiso2
End to end testing is a critical piece to ensure quality and avoid regressions. In this session, we share our journey building an E2E testing pipeline for GridMate components (LWC and Aura) using Cypress, JSForce, FakerJS…
2. June 12, 2014 2
Solution Architecture Is …
− Description of the structure, characteristics and behaviour of a
solution
− The means by which the solution is defined, delivered, managed
and operated
• A solution is an answer to a business problem that may or
may not include a technology component
• Solution architecture is concerned with identifying that
solution or set of solution options and their components
• Generally there are many potential solutions to a problem
with varying suitability
• All solutions are subject to constraints
3. Structured Approach to Solution Architecture
• Objective is to ensure consistency in solution architecture
design options
• Ensure solution addresses all business requirements
• Provide checklist to validate solution design options
• Design realistic and achievable solutions that meet the
business needs
• Adapt elements of TOGAF to assist with structured
solution design
June 12, 2014 3
4. June 12, 2014 4
Solution Architecture In Context
Business
Objectives
Business
Operational
Model
Enterprise
Architecture
Solution
Delivery
Management
And
Operations
Business
Processes
Business
Systems
Business
Strategy
Solution
Architecture
5. Solution Architecture
June 12, 2014 5
Enterprise
Architecture
Solution
Delivery
Business
Systems
Solution
Architecture
Takes the
requirements for
solutions to
business needs
Ensures compliance
with overall systems
architecture
standards
Designs solution options
based on requirements
subject to standards and
other solution constraints
that are then implemented
6. Solution Architecture
June 12, 2014 6
Enterprise
Architecture
Solution
Delivery
Business
Systems
Solution
Architecture
Takes the
requirements for
solutions to
business needs
Ensures compliance
with overall systems
architecture
standards
Designs solution options
based on requirements
subject to standards and
other solution constraints
that are then implemented
Goal is to ensures
solutions implemented
deliver business
requirements
accurately, efficiently
and in a timely manner
with no surprises
7. June 12, 2014 7
Solution Architecture In Context
Business
Strategy
Business
Objectives
Business
Operational
Model
Enterprise
Architecture
Business
Processes
Business
Systems
Solution
Architecture
Solution
Delivery
Management
And Operations
Processes operationalise
business objectives
Operational model defined to
achieve objectives
Architecture defines technology
framework to run operational model
Objectives derived
from strategy
Systems assist with the
operation of processes
Solution architecture defines business systems
design within enterprise architecture principles
Solutions are implemented according
to the solution architecture
8. June 12, 2014 8
Solution Does Not Always Consist Solely Of A New
Application
External
Manual
Interaction
External
Manual
Interaction
External
Manual
Interaction
External
Manual
Interaction
Extended Application
(Other Systems)
System
Component
System
Component
System
Component
External
Component
External
Component
External
Component
Core
Application
9. June 12, 2014 9
Complete View of Solution
System
Component
System
Component
System
Component
External
Component
External
Component
External
Component
Automated
Process
Automated
Process
Automated
Process
External
Manual
Interaction
External
Manual
Interaction
Manual
Process
Manual
Process
External
Manual
Interaction
External
Manual
Interaction
Manual
Process
Manual
Process
10. June 12, 2014 10
Overall Solution Can Be A Combination of
Automated and Manual Processes
Automated
Process
Automated
Process
Automated
Process
Manual
Process
Manual
Process
Manual
Process
Manual
Process
Extended Application
Core
Application
11. June 12, 2014 11
Solution Design and Implementation Sequence
Business Plan
Business Need
Business Benefits
Requirements
Definition
Process Design
Solution Architecture
and Design
Technical and
Detailed Design
Implementation
You Can Iterate
Through These Steps
Multiple Times, Refining
Detail Each Stage
12. June 12, 2014 12
TOGAF Enterprise Architecture Development and
Implementation Process
Architecture
Change
Management
Implementation
Governance
Migration
Planning
Opportunities
and Solutions
Technology
Architecture
Information
Systems
Architecture
Business
Architecture
Architecture
Vision
Requirements
Management
Data
Architecture
Solutions and
Application
Architecture
Business solutions fit into these
areas of the TOGAF framework
13. Extended Solution ViewsCore Solution Views
June 12, 2014 13
Solution Architecture Dimensions/Views
Solution
Architecture
Dimensions
Business
View
Functional
View
Data
View
Technical
View
Implementation
View
Management
And
Operation
14. Core Views and Extended Views
• Core Solution Architecture Views – concerned with the
kernel of the solution
− Business
− Functional
− Data
• Extended Solution Architecture Views – concerned with
solution implementation and operation
− Technical
− Implementation
− Management and Operation
June 12, 2014 14
15. Solution Architecture Dimensions/Views
• Dimensions/views are structured sets of requirements,
conditions, specifications, provisions, concerns and
fundamentals for each dimension of the overall solution
• Core dimensions/views define what the solution must do
and the results expected
• Extended dimensions/views define how the solution must
be implemented, managed and operated
June 12, 2014 15
17. Generalised Solution Architecture
• Sub-System 1 - performs primary activities, functions that accepts
and process inputs, performs transformations and creates and
presents outputs, divided into multiple components, implements
and actualises processes and activities
• Sub-System 2 - monitors, audits, measures, manages performance
and activities of the components of sub-system 1
• Sub-System 3 - controls operation and communication and storage
of data of an between the components of sub-system 1 and
between sub-system 1 and sub-system 2
June 12, 2014 17
19. Solution Core Views
Business and Process
View
Processes Enabled and
Actualised by Solution and its
Functions
Data View
Range of Data Being
Processed/Handled
Functionaland
ResultsView
W
hatisGenerated/
Created/
Achieved/
Output
June 12, 2014 19
20. Solution Core Views And Their Interrelationships
Data View
Range of Data
Being Processed/
Handled
Business and
Process View
Processes Enabled
and Actualised by
Solution and
its Functions
Functions and
Results View
What is Generated/
Created/Achieved
Functions
Generate
Results
Consist of
Created or
Transformed
Data
Business
Processes
Read and
Generate Data
Processes Are
Implemented by
Functions that
Generate ResultsJune 12, 2014 20
21. Business and Process View And Decomposition
Process 1
Activity 1.1 Activity 1.N
Task 1.1.1
Step 1.1.1.1 Step 1.1.1.N
Task 1.1.N Task 1.N.1 Task 1.N.N
Step 1.N.N.1 Step 1.N.N.N
Process N…
…
… …
… …
June 12, 2014 21
22. Data View And Decomposition
Data Type 1
Data Element 1.1 Data Element 1.N
Data Attribute
1.1.1
Data Attribute
Value 1.1.1.1
Data Attribute
Value 1.1.1.N
Data Attribute
1.1.N
Data Attribute
1.N.1
Data Attribute
1.N.N
Data Attribute
Value 1.N.N.1
Data Attribute
Value 1.N.N.N
Data Type N…
…
… …
… …
June 12, 2014 22
23. Functions/Results/Outputs View And Decomposition
Output 1
Output Element
1.1
Output Element
1.N
Output Attribute
1.1.1
Output Attribute
Value 1.1.1.1
Output Attribute
Value 1.1.1.N
Output Attribute
1.1.N
Output Attribute
1.N.1
Output Attribute
1.N.N
Output Attribute
Value 1.N.N.1
Output Attribute
Value 1.N.N.N
Output N…
…
… …
… …
June 12, 2014 23
25. June 12, 2014 25
Dimensions/Views Of Solution Architecture
Solution
Architecture
Dimensions
Business View Functional View Technical View
Implementation
View
Data View
Context
Purpose
Characteristics
Context
Stakeholders
Characteristics
Context
Structure
Operation
Development
Characteristics
Context
Artefacts/
Products
Execution
Characteristics
Context
Entities
Roles
Interfaces
Characteristics
Management
and Operations
View
Context
Operational
Processes
Support
Operation
Characteristics
26. June 12, 2014 26
Business And Process View Topics
Business Requirements View
Business Context Purpose Characteristics
Business Environment
Resources, Skills and Experience
Products, Services and Value
Propositions
Value Chain
Stakeholders
Business Processes
Availability, Continuity and Resilience
Cost and Affordability
Flexibility and Ability to Evolve
Ease of Implementation
Suitability and Efficiency
Performance
Reliability
Manageability and Ease of Operation
Linkage to Other Systems
Stability
Security
Usability
27. June 12, 2014 27
Functional And Results View Topics
Functional View
Functional Context Purpose Characteristics
Related Systems
Operational Processes
Products, Services and Value
Propositions
Value Chain
Stakeholders
Business Processes
Availability, Continuity and Resilience
Cost and Affordability
Flexibility and Ability to Evolve
Ease of Implementation
Suitability and Efficiency
Performance
Reliability
Manageability and Ease of Operation
Linkage to Other Systems
Scalability
Security
Usability
28. June 12, 2014 28
Technical View Topics
Technical View
Technical Context Technical Configuration Operation
Implementation
Environment and Tools
Development Approach
Language
Framework/Systems
Availability, Continuity
and Resilience
Cost and Affordability
Flexibility and Ability to
Evolve
Ease of Implementation
Suitability and
Efficiency
Performance
Reliability
Manageability and Ease
of Operation
Linkage to Other
Systems
Scalability
Security
Usability
Innovation and Growth Characteristics
System Structure
Hardware Infrastructure
Software Infrastructure
System Operation
System Management
and Administration
System Lifecycle
System Change and
Growth
Data Infrastructure
Integration
Infrastructure
29. June 12, 2014 29
Implementation View Topics
Technical View
Implementation Context
Implementation
Artefacts/Products
Execution
Implementation Environment
Development Approach
Language
Framework/Systems
Availability, Continuity and
Resilience
Cost and Affordability
Flexibility and Ability to
Evolve
Ease of Implementation
Suitability and Efficiency
Performance
Reliability
Manageability and Ease of
Operation
Linkage to Other Systems
Scalability
Security
Usability
Characteristics
Solution Elements
Delivered Components
Collateral
Governance
Implementation Organisation
Supporting Material
Implementation Process
Delivery Plan
Configuration
Financial Management
Solution Validation
30. Data View Topics
June 12, 2014 30
Data View
Data Context Entitles Interfaces
Data Model
Reference and Master
Data
Availability, Continuity
and Resilience
Cost and Affordability
Flexibility and Ability to
Evolve
Ease of Implementation
Suitability and Efficiency
Performance
Reliability
Manageability and Ease
of Operation
Storage and Capacity
Scalability
Security
Usability
Analysis and Reporting Characteristics
Data Entities
Relationships
Access Rights and
Permissions
Sources and Targets
Transformations
Reporting
Analysis
Data Types
Data Types
Conversion/Migration
Data Volumes
Data Velocity
Data Variety
31. Management and Operation View Topics
June 12, 2014 31
Management and
Operation View
Management and
Operation Context
Operational Processes Support
Service Management
Framework
Operational Framework
Transition
Business Readiness
Availability, Continuity
and Resilience
Cost and Affordability
Flexibility and Ability to
Evolve
Ease of Implementation
Suitability and Efficiency
Performance
Reliability
Manageability and Ease
of Operation
Linkage to Other Systems
Scalability
Security
Usability
Operation Characteristics
Capacity
Availability, Continuity
and Resilience
Change
Support Model
Support Processes
Deployment/
Maintenance Structure
Deployment/
Maintenance Process
Service Level
Service Desk
Service Management
Processes
Configuration
Release and Deployment
Incident
Problem
Organisational Change
Steady State
Alerting and Monitoring
Backup and Recovery
Service Level
Management
32. June 12, 2014 32
Mapping TOGAF Enterprise Architecture Process To
Solution Architecture Definition
TOGAF Phase
D: Technology
Architecture
TOGAF Phase
C: Information
Systems
Architecture
TOGAF Phase
B: Business
Architecture
TOGAF Phase
C1: Data
Architecture
TOGAF Phase
C2: Solutions
and
Application
Architecture
Business View
Data View
Technical View
Functional View
Implementation
View
Management and
Operation View
SolutionArchitecture
Views/Dimensions
34. Solution Architecture Design Boundaries
June 12, 2014 34
Enterprise Architecture Defines the
Solution Technical Boundary
Business View
Data View
Technical View
Functional View
Implementation
View
Management
and Operation
View
Solution
Architecture
Solution
Architecture
Defines the
Solution
Scope
Boundary
35. Designing The Solution
• Overall solution design is constrained both by enterprise
architecture and solution architecture views
• There are many possible solution options to a business
requirement or problem
− Solution can be manual or automated to a lesser or greater extent
− Solution can involve enhancing existing system and/or process or
developing new system and/or process
− These constraints form boundaries to the solution design
June 12, 2014 35
36. Solution Design Factors, Limitations And Boundaries
• Core Constraints – concerned with essential solution
attributes
− Enterprise Architecture
− Solution Architecture Views/Dimensions
− Existing or New System
− Degree of Automation
• Extended Constraints – concerned with solution
implementation and operation
− Resources
− Finance
− Timescale
− Expected Life
June 12, 2014 36
37. Core Solution Design Factors, Limitations And
Boundaries
Degree of Automation of Solution
Solution
Architecture
View Design
Constraints
Enterprise Architecture Constraints
Use
Existing
System or
Create New
System
Range of
Solution
Options
June 12, 2014 37
38. Extended Solution Design Factors, Limitations And
Boundaries
• Other implementation and operation-related constraints
that will affect the solution options:
− Resources and their availability
− Timescale and urgency of solution
− Cost and available finance
− Likely duration of solution
June 12, 2014 38
41. Solution Architecture Dimensions/Views And
Solution Design Factors, Limitations And Boundaries
Extended Views
Core Views
June 12, 2014 41
Solution Design Factors,
Limitations And
Boundaries
Solution Architecture
Dimensions/Views
42. Solution Architecture Dimensions/Views And
Solution Design Factors, Limitations And Boundaries
Enterprise
Architecture
Technical View
Implementation View
Management and
Operation View
Business View
Data View
Functional View
Degree of
Automation
Finance
Timescale
Existing or
New System
Resources
Expected Life
June 12, 2014 42
43. June 12, 2014 43
Mapping TOGAF Enterprise Architecture Process To
Solution Architecture Definition
TOGAF Phase
D: Technology
Architecture
TOGAF Phase
C: Information
Systems
Architecture
TOGAF Phase
B: Business
Architecture
TOGAF Phase
C1: Data
Architecture
TOGAF Phase
C2: Solutions
and
Application
Architecture
Business View
Data View
Technical View
Functional View
Implementation
View
Management and
Operation View
SolutionArchitecture
Views/Dimensions
44. Steps For TOGAF View/Dimension Analysis And
Development
• Common set of steps across four solution architecture
views/dimensions common to TOGAF
1. Select reference models, viewpoints, and tools
2. Develop baseline view/dimension architecture description
3. Develop target view/dimension architecture description
4. Perform gap analysis
5. Define roadmap components
6. Resolve impacts across the architecture landscape
7. Conduct formal stakeholder review
8. Finalise the view/dimension architecture
9. Create view/dimension architecture definition document
June 12, 2014 44
45. Steps For TOGAF View/Dimension Analysis And
Development
• Use TOGAF framework to give a rigour to the solution
architecture analysis and design
• Modify as required to suit the depth of the analysis
• Can iterate through the steps with varying levels of
analysis as solution is articulated
June 12, 2014 45
46. TOGAF Steps For Business Dimension/View Analysis
And Design
June 12, 2014 46
47. Step 1 - Select Reference Models, Viewpoints, and
Tools (1)
• Select relevant Business Architecture resources (reference models, patterns, etc.)
from the Architecture Repository, on the basis of the business drivers, and the
stakeholders and concerns
• Select relevant Business Architecture viewpoints (e.g., operations, management,
financial); i.e. those that will enable the architect to demonstrate how the
stakeholder concerns are being addressed in the Business Architecture
• Identify appropriate tools and techniques to be used for capture, modeling, and
analysis
• Determine Overall Modelling Process
− For each viewpoint, select the models needed to support the specific view required,
using the selected tool or method
− Ensure that all stakeholder concerns are covered
− Identify the key business functions within the scope of the architecture, and maps those
functions onto the business units within the organisation
− Breakdown business-level functions across actors and business units to allow the actors
in a function to be identified and permits a breakdown into services
supporting/delivering that functional capability
− Breakdown a function or business service through process modeling to allow the
elements of the process to be identified and permit the identification of lower-level
business services or functions
June 12, 2014 47
48. Step 1 - Select Reference Models, Viewpoints, and
Tools (2)
• Identify Required Service Granularity Level, Boundaries, and
Contracts
− Business Architecture phase therefore needs to identify which components of
the architecture are functions and which are services
• Business services are specific functions that have explicit, defined boundaries that
are explicitly governed
• Services are distinguished from functions through the explicit definition of a service
contract
• A service contract covers the business/functional interface and also the
technology/data interface
− Business Architecture will define the service contract at the
business/functional level, which will be expanded on in the Application and
Technology Architecture phases
− Granularity of business services should be determined according to the
business drivers, goals, objectives, and measures for this area of the business
June 12, 2014 48
49. Step 1 - Select Reference Models, Viewpoints, and
Tools (3)
• Identify Required Catalogs of Business Building Blocks
− Catalogs capture inventories of the core assets of the business
− Catalogs form the raw material for development of matrices and
views and also act as a key resource for portfolio managing
business and IT capability
− Develop some or all of the following catalogs:
• Organisation/Actor catalog
• Driver/Goal/Objective catalog
• Role catalog
• Business Service/Function catalog
• Location catalog
• Process/Event/Control/Product catalog
• Contract/Measure catalog
June 12, 2014 49
50. Step 1 - Select Reference Models, Viewpoints, and
Tools (4)
• Identify Required Matrices
− Matrices show the core relationships between related model
entities
− Matrices form the raw material for development of views and
also act as a key resource for impact assessment, carried out as a
part of gap analysis
• Business interaction matrix - showing dependency and communication
between business units and actors
• Actor/role matrix - showing the roles undertaken by each actor
June 12, 2014 50
51. Step 1 - Select Reference Models, Viewpoints, and
Tools (5)
• Identify Required Diagrams
− Diagrams present the Business Architecture information from a
set of different perspectives according to the requirements of the
stakeholders
• Business Footprint diagram
• Business Service/Information diagram
• Functional Decomposition diagram
• Goal/Objective/Service diagram
• Use-case diagram
• Organisation Decomposition diagram
• Process Flow diagram
• Events diagram
June 12, 2014 51
52. Step 1 - Select Reference Models, Viewpoints, and
Tools (6)
• Identify Types of Requirement to be Collected
− Once the Business Architecture catalogs, matrices, and diagrams have been
developed, architecture modeling is completed by formalising the business-
focused requirements for implementing the Target Architecture
− Requirements may relate to the business domain, or may provide
requirements input into the Data, Application, and Technology Architectures
− Types of requirement
• Functional requirements
• Non-functional requirements
• Assumptions
• Constraints
• Domain-specific Business Architecture principles
• Policies
• Standards
• Guidelines
• Specifications
June 12, 2014 52
53. Step 2 - Develop Baseline Business Architecture
Description
• Develop a Baseline Description of the existing Business
Architecture, to the extent necessary to support the Target
Business Architecture
• Scope and level of detail to be defined will depend on the
extent to which existing business elements are likely to be
carried over into the Target Business Architecture
June 12, 2014 53
54. Step 3 - Develop Target Business Architecture
Description
• Develop a Target Description for the Business Architecture,
to the extent necessary to support the Architecture Vision
• Scope and level of detail to be defined will depend on the
relevance of the business elements to attaining the Target
Architecture Vision
June 12, 2014 54
55. Step 4 - Perform Gap Analysis
• Verify the architecture models for internal consistency and
accuracy
• Perform trade-off analysis to resolve conflicts (if any)
among the different views
• Validate that the models support the principles, objectives,
and constraints
• Test architecture models for completeness against
requirements
• Identify gaps between the baseline and target
June 12, 2014 55
56. Step 5 - Define Roadmap Components
• Create a business roadmap to prioritise activities over the
coming phases
• Initial Business Architecture roadmap will be used as raw
material to support more detailed definition of a
consolidated, cross-discipline roadmap within the
Opportunities and Solutions phase
June 12, 2014 56
57. Step 6 - Resolve Impacts Across the Architecture
Landscape
• Understand any wider impacts or implications of proposed
Business Architecture
− Does this Business Architecture create an impact on any pre-
existing architectures?
− Have recent changes been made that impact on the Business
Architecture?
− Are there any opportunities to leverage work from this Business
Architecture in other areas of the organisation?
− Does this Business Architecture impact other projects (including
those planned as well as those currently in progress)?
− Will this Business Architecture be impacted by other projects
(including those planned as well as those currently in progress)?
June 12, 2014 57
58. Step 7 - Conduct Formal Stakeholder Review
• Check the original motivation for the architecture project
and the Statement of Architecture Work against the
proposed Business Architecture
• Is fit for the purpose of supporting subsequent work in the
other architecture domains?
• Refine the proposed Business Architecture but only if
necessary
June 12, 2014 58
59. Step 8 - Finalise the Business Architecture
• Select standards for each of the building blocks re-using as much as
possible from the reference models selected from the Architecture
Repository
• Document each building block
• Conduct final cross-check of overall architecture against business
goals
• Document reason for building block decisions in the architecture
document
• Document final requirements traceability report
• Document final mapping of the architecture within the Architecture
Repository and publish via the Architecture Repository
• Finalise all the work products, such as gap analysis results
June 12, 2014 59
60. Step 9 - Create Architecture Definition Document
• Document reasons for building block decisions in the
Architecture Definition Document
• Prepare the business sections of the Architecture
Definition Document
− A business footprint (a high-level description of the people and
locations involved with key business functions)
− A detailed description of business functions and their information
needs
− A management footprint (showing span of control and
accountability)
− Standards, rules, and guidelines showing working practices,
legislation, financial measures, etc.
− A skills matrix and set of job descriptions
June 12, 2014 60
61. TOGAF Steps For Data Dimension/View Analysis And
Design
June 12, 2014 61
62. Step 1 - Select Reference Models, Viewpoints, and Tools (1)
• Select relevant Data Architecture resources (reference models, patterns, etc.)
from the Architecture Repository, on the basis of the business drivers, and the
stakeholders and concerns
• Select relevant Data Architecture viewpoints (e.g., operations, management,
financial); i.e. those that will enable the architect to demonstrate how the
stakeholder concerns are being addressed in the Data Architecture
• Identify appropriate tools and techniques to be used for data capture, modeling,
and analysis
• Determine Overall Modelling Process
− For each viewpoint, select the models needed to support the specific view required,
using the selected tool or method
− Ensure that all stakeholder concerns are covered
− Collect data-related models from existing Business Architecture and Application
Architecture materials
− Rationalise data requirements and align with any existing organisation data catalogs
and models - this allows the development of a data inventor y and entity relationship
− Update and develop matrices across the architecture by relating data to business
service, business function, access rights, and application
− Elaborate Data Architecture views by examining how data is created, distributed,
migrated, secured, and archived
June 12, 2014 62
63. Step 1 - Select Reference Models, Viewpoints, and Tools (2)
• Identify Required Catalogs of Data Building Blocks
− Capture organisation’s data inventory as a catalog within the
Architecture Repository
− Create an inventory of the data needed to be in place to support
the Architecture Vision
− Refer to the Business Service/Information diagram created during
the Business Architecture phase, showing the key data entities
required by the main business services
− Consolidate the data requirements in a single location
− Refine the data inventory to achieve semantic consistency and to
remove gaps and overlaps
June 12, 2014 63
64. Step 1 - Select Reference Models, Viewpoints, and Tools (3)
• Identify Required Matrices
− Matrices show the core relationships between related model entities
− Form the raw material for development of diagrams and also act as a key
resource for impact assessment
− Understand how data is created, maintained, transformed, and passed to
other applications, or used by other applications
− Note gaps such as entities that never seem to be created by an application or
data created but never used
− Update and refine the architectural diagrams of how data relates to other
aspects of the architecture
− Suggested matrices
• Data Entity/Business Function (showing which data supports which functions and
which business function owns which data)
• Business Service/Information (developed during the Business Architecture phase)
• System/Data (developed across the Application Architecture and Data Architecture
phases)
June 12, 2014 64
65. Step 1 - Select Reference Models, Viewpoints, and Tools (4)
• Identify Required Diagrams
− Diagrams present the Data Architecture information from a set of
different perspectives according to the requirements of the
stakeholders
− Once the data entities have been refined, a diagram of the
relationships between entities and their attributes can be
produced
• Class diagram
• Data Dissemination diagram
• Data Lifecycle diagram
• Data Security diagram
• Data Migration diagram
• Class Hierarchy diagram
June 12, 2014 65
66. Step 1 - Select Reference Models, Viewpoints, and Tools (5)
• Identify Types of Requirement to be Collected
− Once the Data Architecture catalogs, matrices, and diagrams have
been developed, architecture modeling is completed by
formalising the business-focused requirements for implementing
the Target Architecture
− Types of requirement
• Functional requirements
• Non-functional requirements
• Assumptions
• Constraints
• Domain-specific Data Architecture principles
• Policies
• Standards
• Guidelines
• Specifications
June 12, 2014 66
67. Step 2 - Develop Data Business Architecture Description
• Develop a Baseline Description of the existing Data
Architecture, to the extent necessary to support the Target
Business Architecture
• Scope and level of detail to be defined will depend on the
extent to which existing data elements are likely to be
carried over into the Target Data Architecture
June 12, 2014 67
68. Step 3 - Develop Target Business Architecture Description
• Develop a Target Description for the Data Architecture, to
the extent necessary to support the Architecture Vision
• Scope and level of detail to be defined will depend on the
relevance of the business elements to attaining the Target
Architecture Vision
June 12, 2014 68
69. Step 4 - Perform Gap Analysis
• Verify the architecture models for internal consistency and accuracy
• Perform trade-off analysis to resolve conflicts (if any) among the
different views
• Validate that the models support the principles, objectives, and
constraints
• Test architecture models for completeness against requirements
• Identify gaps between the baseline and target
− Create gap matrix
− Identify building blocks to be carried over, classifying as either changed or
unchanged
− Identify eliminated building blocks
− Identify new building blocks
− Identify gaps and classify as those that should be developed and those that
should be procured
June 12, 2014 69
70. Step 5 - Define Roadmap Components
• Create a data business roadmap to prioritise activities over
the coming phases
• Initial Data Architecture roadmap will be used as raw
material to support more detailed definition of a
consolidated, cross-discipline roadmap within the
Opportunities and Solutions phase
June 12, 2014 70
71. Step 6 - Resolve Impacts Across the Architecture Landscape
• Understand any wider impacts or implications of proposed
Data Architecture
− Does this Data Architecture create an impact on any pre-existing
architectures?
− Have recent changes been made that impact on the Data
Architecture?
− Are there any opportunities to leverage work from this Data
Architecture in other areas of the organisation?
− Does this Data Architecture impact other projects (including those
planned as well as those currently in progress)?
− Will this Data Architecture be impacted by other projects
(including those planned as well as those currently in progress)?
June 12, 2014 71
72. Step 7 - Conduct Formal Stakeholder Review
• Check the original motivation for the architecture project
and the Statement of Architecture Work against the
proposed Data Architecture
• Is fit for the purpose of supporting subsequent work in the
other architecture domains?
• Identify any areas where the Solution and Application
Architecture may need to change to cater for changes in
the Data Architecture (or to identify constraints on the
Solution and Application Architecture about to be
designed)
• Refine the proposed Data Architecture but only if
necessary
June 12, 2014 72
73. Step 8 - Finalise the Data Architecture
• Select standards for each of the building blocks re-using as much as
possible from the reference models selected from the Architecture
Repository
• Document each building block
• Conduct final cross-check of overall architecture against business
goals
• Document reason for building block decisions in the architecture
document
• Document final requirements traceability report
• Document final mapping of the architecture within the Architecture
Repository and publish via the Architecture Repository
• Finalise all the work products, such as gap analysis results
June 12, 2014 73
74. Step 9 - Create Architecture Definition Document
• Document reasons for building block decisions in the
Architecture Definition Document
• Prepare Data Architecture sections of the Architecture
Definition Document
− Business data model
− Logical data model
− Data management process model
− Data Entity/Business Function matrix
− Data interoperability requirements
June 12, 2014 74
75. TOGAF Steps For Functional Dimension/View
Analysis And Design
June 12, 2014 75
76. Step 1 - Select Reference Models, Viewpoints, and Tools (1)
• Review and validate (or generate, if necessary) the set of application
principles
− Form part of an overarching set of architecture principles
• Select relevant Application Architecture resources (reference
models, patterns, etc.) from the Architecture Repository, on the
basis of the business drivers, and the stakeholders and concerns
• Select relevant Application Architecture viewpoints (for example,
stakeholders of the applications, viewpoints relevant to functional
and individual users of applications, etc.); i.e. those that will enable
the architect to demonstrate how the stakeholder concerns are
being addressed in the Application Architecture
• Identify appropriate tools and techniques to be used for data
capture, modeling, and analysis
• Consider using platform-independent descriptions of business logic
− Isolate the business logic from changes to the underlying platform and
implementation technology
June 12, 2014 76
77. Step 1 - Select Reference Models, Viewpoints, and Tools (2)
• Determine Overall Modeling Process
− For each viewpoint, select the models needed to support the
specific view required, using the selected tool or method
− Ensure that all stakeholder concerns are covered
− Process steps
• Understand the list of applications or application components that are
required, based on the baseline Application Portfolio, what the
requirements are, and the business architecture scope
• Identify logical applications and the most appropriate physical applications
• Develop matrices across the architecture by relating applications to
business service, business function, data, process, etc.
• Elaborate a set of Application Architecture views by examining how the
application will function, capturing integration, migration, development,
and operational concerns
− The level of granularity should be sufficient to enable
identification of gaps and the scope of candidate work packages
June 12, 2014 77
78. Step 1 - Select Reference Models, Viewpoints, and Tools (3)
• Identify Required Catalogs of Application Building Blocks
− Capture organisation’s Application Portfolio as a catalog within
the Architecture Repository
• Application Portfolio catalog
• Interface catalog
June 12, 2014 78
79. Step 1 - Select Reference Models, Viewpoints, and Tools (4)
• Identify Required Matrices
− Matrices show the core relationships between related model entities
− Form the raw material for development of diagrams and also act as a key resource for
impact assessment
− Once the baseline Application Portfolio has been assembled, it is necessary to map the
applications to their purpose in supporting the business
• Initial mapping should focus on business services within the Business Architecture
− Once applications are mapped to business services, it will also be possible to make
associations from applications to data
• Refer to Phase C1: Information Systems Architectures - Data Architecture
− Identify user and organisational dependencies on applications
− Specifically consider the operational support business unit
− Update and refine the architectural diagrams of how data relates to other aspects of
the architecture
− Examine application dependencies on shared operations capabilities and produce a
diagram on how each application is effectively operated and managed
− Suggested matrices
• System/Business Unit matrix
• Role/System matrix
• Application Interaction matrix
• System/Function matrix
June 12, 2014 79
80. Step 1 - Select Reference Models, Viewpoints, and Tools (5)
• Identify Required Diagrams
− Diagrams present the Application Architecture information from a set of
different perspectives according to the requirements of the stakeholders
− Once the desired functionality of an application is known, it is necessary to
perform an internal assessment of how the application should be best
structured to meet its requirements
• Packaged applications
− Numbers of configuration options, add-on modules
• Custom developed applications
− Identify the high-level structure of the application in terms of modules or sub-
systems as a foundation to organise design activity
− Once the application entities have been refined, a diagram of the relationships
between entities and their attributes can be produced
• Application Communication diagram
• Application and User Location diagram
• Enterprise Manageability diagram
• Process/System Realisation diagram
• Application Migration diagram
• Software Distribution diagram
• Software Engineering diagram
June 12, 2014 80
81. Step 1 - Select Reference Models, Viewpoints, and Tools (6)
• Identify Types of Requirement to be Collected
− Once the Application Architecture catalogs, matrices, and
diagrams have been developed, architecture modeling is
completed by formalising the application-focused requirements
for implementing the Target Architecture
− Types of requirement
• Functional requirements
• Non-functional requirements
• Assumptions
• Constraints
• Domain-specific Application Architecture principles
• Policies
• Standards
• Guidelines
• Specifications
June 12, 2014 81
82. Step 2 - Develop Application Business Architecture
Description
• Develop a Baseline Description of the existing Application
Architecture, to the extent necessary to support the Target
Business Architecture
• Scope and level of detail to be defined will depend on the
extent to which existing data elements are likely to be
carried over into the Target Application Architecture
June 12, 2014 82
83. Step 3 - Develop Target Application Architecture Description
• Develop a Target Description for the Application
Architecture, to the extent necessary to support the
Architecture Vision, Target Business Architecture, and
Target Data Architecture
• Scope and level of detail to be defined will depend on the
relevance of the business elements to attaining the Target
Architecture Vision
June 12, 2014 83
84. Step 4 - Perform Gap Analysis
• Verify the architecture models for internal consistency and
accuracy
• Test architecture models for completeness against
requirements
• Identify gaps between the baseline and target
− Create gap matrix
− Identify building blocks to be carried over, classifying as either
changed or unchanged
− Identify eliminated building blocks
− Identify new building blocks
− Identify gaps and classify as those that should be developed and
those that should be procured
June 12, 2014 84
85. Step 5 - Define Roadmap Components
• Create an application business roadmap to prioritise
activities over the coming phases
• Initial Application Architecture roadmap will be used as
raw material to support more detailed definition of a
consolidated, cross-discipline roadmap within the
Opportunities and Solutions phase
June 12, 2014 85
86. Step 6 - Resolve Impacts Across the Architecture Landscape
• Understand any wider impacts or implications of proposed
Application Architecture
− Does this Application Architecture create an impact on any pre-
existing architectures?
− Have recent changes been made that impact on the Application
Architecture?
− Are there any opportunities to leverage work from this
Application Architecture in other areas of the organisation?
− Does this Application Architecture impact other projects
(including those planned as well as those currently in progress)?
− Will this Application Architecture be impacted by other projects
(including those planned as well as those currently in progress)?
June 12, 2014 86
87. Step 7 - Conduct Formal Stakeholder Review
• Check the original motivation for the architecture project
and the Statement of Architecture Work against the
proposed Application Architecture
• Identify any areas where the where the Business and Data
Architectures (e.g., business practices) may need to
change to cater for changes in the Application Architecture
(for example, changes to for ms or procedures, application
systems, or database systems)
• Identify any constraints on the Technology Architecture
(especially the infrastructure) about to be designed
June 12, 2014 87
88. Step 8 - Finalise the Application Architecture
• Select standards for each of the building blocks re-using as much as
possible from the reference models selected from the Architecture
Repository
• Document each building block
• Conduct final cross-check of overall architecture against business
goals
• Document reason for building block decisions in the architecture
document
• Document final requirements traceability report
• Document final mapping of the architecture within the Architecture
Repository and publish via the Architecture Repository
• Finalise all the work products, such as gap analysis results
June 12, 2014 88
89. Step 9 - Create Architecture Definition Document
• Document reasons for building block decisions in the
Architecture Definition Document
• Prepare Application Architecture sections of the
Architecture Definition Document
June 12, 2014 89
90. TOGAF Steps For Technical Dimension/View Analysis
And Design
June 12, 2014 90
91. Step 1 - Select Reference Models, Viewpoints, and
Tools (1)
• Review and validate the set of technology principles
• Select relevant Technology Architecture resources
(reference models, patterns, etc.) from the Architecture
Repository
• Select relevant Technology Architecture viewpoints that
will enable the architect to demonstrate how the
stakeholder concerns are being addressed in the
Technology Architecture
• Identify appropriate tools and techniques to be used for
capture, modeling, and analysis, in association with the
selected viewpoints
June 12, 2014 91
92. Step 1 - Select Reference Models, Viewpoints, and
Tools (2)
• Determine Overall Modelling Process
− For each viewpoint, select the models needed to support the
specific view required, using the selected tool or method
− Develop a Technology Architecture
• Define a classification of platform services and logical technology
components (including standards)
• Identify relevant locations where technology is deployed
• Carr y out a physical inventor y of deployed technology and abstract up to
fit into the classification
• Look at application and business requirements for technology
• Is the technology in place fit-for-purpose to meet new requirements
• Deter mine configuration of the selected technology
• Determine impact
− Sizing and costing
− Capacity planning
− Installation/governance/migration impacts
June 12, 2014 92
93. Step 1 - Select Reference Models, Viewpoints, and
Tools (3)
• Determine Overall Modelling Process
− Technology Architecture may be impacted by earlier decisions made around
service granularity/level of detail and service boundaries
• Performance - Coarse-grained services contain several units of functionality with
potentially varying nonfunctional requirements, so platform performance should be
considered
• Maintainability - If service granularity is too coarse, then introducing changes to
that ser vice becomes difficult and impacts the maintenance of the service and the
platform on which it is delivered
• Location and Latency - Services might interact with each other over remote links
and inter-service communication will have in-built latency
• Availability - Service invocation is subject to network and/or service failure so high
communication availability is an important consideration during service
decomposition and defining service granularity
− Product selection processes may occur within the Technology Architecture
phase where existing products are re-used, incremental capacity is being
added, or product selection decisions are a constraint during project initiation
− Where product selection deviates from existing standards, involves significant
effort, or has wide-ranging impact, this activity should be flagged as an
opportunity and addressed through the Opportunities and Solutions phase
June 12, 2014 93
94. Step 1 - Select Reference Models, Viewpoints, and
Tools (4)
• Identify Required Catalogs of Technology Building Blocks
− Catalogs are inventories of the core assets of the business
− Catalogs for m the raw material for development of matrices and diagrams and
also act as a key resource for portfolio managing business and IT capability
− Based on existing technology catalogs and analysis of applications carried out
in the Application Architecture phase, collect a list of products in use
− If the requirements identified in the Application Architecture are not met by
existing products, extend the product list by examining products available on
the market that provide the functionality and meet the required standards
− If technology standards are currently in place, apply these to the technology
component catalog to gain a baseline view of compliance with technology
standards
− Create catalogs
• Technology standards
• Technology portfolio
June 12, 2014 94
95. Step 1 - Select Reference Models, Viewpoints, and
Tools (5)
• Identify Required Matrices
− Matrices show the core relationships between related model
entities
− Create System/Technology matrix
June 12, 2014 95
96. Step 1 - Select Reference Models, Viewpoints, and
Tools (6)
• Identify Required Diagrams
− Diagrams present the Technology Architecture information from a set of different
perspectives (viewpoints) according to the requirements of the stakeholders
• Provide a link between platform requirements and hosting requirements
− For major baseline applications or application platforms (where multiple applications
are hosted on the same infrastructure stack), produce a stack diagram showing how
hardware, operating system, software infrastructure, and packaged applications
combine
− For each environment, produce a logical diagram of hardware and software
infrastructure showing the contents of the environment and logical communications
between components
• Where available, collect capacity information on the deployed infrastructure
− For each environment, produce a physical diagram of communications infrastructure,
such as routers, switches, firewalls, and network links
• Where available, collect capacity information on the communications infrastructure
− Create diagrams
• Environments and Locations diagram
• Platform Decomposition diagram
• Processing diagram
• Networked Computing/Hardware diagram
• Communications Engineering diagram
June 12, 2014 96
97. Step 1 - Select Reference Models, Viewpoints, and
Tools (7)
• Identify Types of Requirement to be Collected
− Once the Technology Architecture catalogs, matrices, and diagrams have been
developed, architecture modeling is completed by formalising the data-
focused requirements for implementing the Target Architecture
− Identify types of requirement that must be met by the architecture
implementation
• Functional requirements
• Non-functional requirements
• Assumptions
• Constraints
• Domain-specific Technology Architecture principles
• Policies
• Standards
• Guidelines
• Specifications
June 12, 2014 97
98. Step 1 - Select Reference Models, Viewpoints, and
Tools (8)
• Select Services
− Services portfolios are combinations of basic services from the
service categories in the Technical Reference Model that do not
conflict
• Requirements for organisation-specific elements or pre-existing decisions
• Pre-existing and unchanging organisational elements
• Inherited external environment constraints
− For each building block, build up a service description portfolio as
a set of non-conflicting ser vices
− Set of services must be tested to ensure that the functionality
provided meets application requirements
June 12, 2014 98
99. Step 2 - Develop Baseline Business Architecture
Description
• Develop a Baseline Description of the existing Technology
Architecture to the extent necessary to support the Target
Technology Architecture
• Scope and level of detail to be defined will depend on the extent to
which existing business elements are likely to be carried over into
the Target Business Architecture
• Identify the relevant Technology Architecture building blocks,
drawing on any artifacts held in the Architecture Repository
• Convert the description of the existing environment into the terms
of the organisation’s Foundation Architecture
• Set down a list of key questions which can be used later in the
development process to measure the effectiveness of the new
architecture
• Use the models identified within Step 1 of Phase D as a guideline for
creating new architecture content to describe the Baseline
Architecture
June 12, 2014 99
100. Step 3 - Develop Target Technology Architecture
Description
• Develop a Target Description for the Technology Architecture, to the
extent necessary to support the Architecture Vision, Target Business
Architecture, and Target Information Systems Architecture
• Scope and level of detail to be defined will depend on the relevance
of the business elements to attaining the Target Architecture Vision
• Process in the creation of a broad architectural model of the target
system is the conceptualisation of building blocks
• Architecture Building Blocks (ABBs) describe the functionality and
how they may be implemented without the detail introduced by
configuration or detailed design
• Where new architecture models need to be developed to satisfy
stakeholder concerns, use the models identified within Step 1 of
Phase D as a guideline for creating new architecture content to
describe the Target Architecture
June 12, 2014 100
101. Step 4 - Perform Gap Analysis
• Verify the architecture models for internal consistency and accuracy
• Note changes to the viewpoint represented in the selected models
from the Architecture Repository
• Test architecture models for completeness against requirements
• Identify gaps between the baseline and target
− Create gap matrix
− Identify building blocks to be carried over, classifying as either changed or
unchanged
− Identify eliminated building blocks
− Identify new building blocks
− Identify gaps and classify as those that should be developed and those that
should be procured
June 12, 2014 101
102. Step 5 - Define Roadmap Components
• Create a business roadmap to prioritise activities over the
coming phases
• Initial Technology Architecture roadmap will be used as
raw material to support more detailed definition of a
consolidated, cross-discipline roadmap within the
Opportunities and Solutions phase
June 12, 2014 102
103. Step 6 - Resolve Impacts Across the Architecture
Landscape
• Understand any wider impacts or implications of proposed
Technology Architecture
− Does this Technology Architecture create an impact on any pre-
existing architectures?
− Have recent changes been made that impact on the Technology
Architecture?
− Are there any opportunities to leverage work from this
Technology Architecture in other areas of the organisation?
− Does this Technology Architecture impact other projects
(including those planned as well as those currently in progress)?
− Will this Technology Architecture be impacted by other projects
(including those planned as well as those currently in progress)?
June 12, 2014 103
104. Step 7 - Conduct Formal Stakeholder Review
• Check the original motivation for the architecture project
and the Statement of Architecture Work against the
proposed Technology Architecture
• Is fit for the purpose of supporting subsequent work in the
other architecture domains?
• Refine the proposed Technology Architecture but only if
necessary
June 12, 2014 104
105. Phase Step 8 - Finalise the Business Architecture
• Select standards for each of the building blocks re-using as much as
possible from the reference models selected from the Architecture
Repository
• Document each building block
• Conduct final cross-check of overall architecture against business
goals
• Document reason for building block decisions in the architecture
document
• Document final requirements traceability report
• Document final mapping of the architecture within the Architecture
Repository and publish via the Architecture Repository
− From the selected building blocks, identify those that might be re-used
(working practices, roles, business relationships, job descriptions, etc.),
• Finalise all the work products, such as gap analysis results
June 12, 2014 105
106. Step 9 - Create Architecture Definition Document
• Document reasons for building block decisions in the Architecture
Definition Document
• Prepare the business sections of the Architecture Definition
Document
− Fundamental functionality and attributes - semantic, unambiguous including
security capability and manageability
− Dependent building blocks with required functionality and named interfaces
− Interfaces - chosen set, supplied (APIs, data for mats, protocols, hardware
interfaces, standards)
− Map to business/organisational entities and policies
• Use reports and/or graphics generated by modeling tools to
demonstrate key views of the architecture
• Route the document for review by relevant stakeholders and
incorporate feedback
June 12, 2014 106
107. Summary
• The role of solution architecture is to identify answer to a business
problem and set of solution options and their components
• There will be many potential solutions to a problem with varying
suitability
• Solution options are derived from a combination of Solution
Architecture Dimensions/Views which describe characteristics,
features, qualities, requirements and Solution Design Factors,
Limitations And Boundaries which delineate limitations
• Use structured approach to assist with solution design to create
consistency
• TOGAF approach to enterprise architecture can be adapted to
perform analysis and design for elements of Solution Architecture
Dimensions/Views
• Solution architecture is part of the continuum from business
problem to operable solution
108. June 12, 2014 108
More Information
Alan McSweeney
http://ie.linkedin.com/in/alanmcsweeney