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.
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.
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.
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.
Enterprise Business Analysis Capability - Strategic Asset for Business Alignm...Alan McSweeney
Introducing the concept of Enterprise Business Analysis as a strategic resource to achieve business and IT alignment. Alignment means being able to draw a straight Line from business strategy through to delivered and operational solutions implemented to respond to businessn. Business and IT Alignment requires more than just relationship management – it requires actual engagement by IT with the needs of the business.
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)
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
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.
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.
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.
Enterprise Business Analysis Capability - Strategic Asset for Business Alignm...Alan McSweeney
Introducing the concept of Enterprise Business Analysis as a strategic resource to achieve business and IT alignment. Alignment means being able to draw a straight Line from business strategy through to delivered and operational solutions implemented to respond to businessn. Business and IT Alignment requires more than just relationship management – it requires actual engagement by IT with the needs of the business.
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)
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
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.
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.
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.
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.
IT4IT and DevOps Tools Landscape (2020).Rob Akershoek
Complete overview of the IT management tooling landscape 2020. Key market players / vendors in the IT4IT and DevOps tooling ecosystem. Automate and streamline your end-to-end DevOps tool chain.
An example of a successful proof of conceptETLSolutions
In this presentation we explain how to create a successful proof of concept for software, using a real example from our work in the Oil & Gas industry.
Structured Approach to Solution ArchitectureAlan McSweeney
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.
Introduction to Business Architecture - Part 2Alan McSweeney
The first part is available at: https://www.slideshare.net/alanmcsweeney/introduction-to-business-architecture-part-1.
This material describes conducting a specific business architecture engagement. The engagement process is generic and needs to be adapted to each specific application and use. The engagement is a formal process for gathering information and creating a new business function model based on an analysis of that information.
The objective is to create a realistic and achievable target business architecture to achieve the desired business change.
Business architecture is a structured approach to analysing the operation of an existing business function or entire organisation with a view to improving its operations or developing a new business function, with a strong focus on processes and technology. Business architecture is not about business requirements – it is about business solutions and organisation changes to deliver business objectives.
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.
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.
Shadow IT And The Failure Of IT ArchitectureAlan McSweeney
The continued existence and growth of shadow IT gives IT architecture the opportunity show leadership. IT architecture can be the gateway for business IT solution requirements, from initial solution concept through to solution realisation.
Shadow IT is 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. There are many aspects of shadow IT:
• Shadow Projects
• Shadow Data
• Shadow Sourcing
• Shadow Development
• Shadow Solutions
• Shadow Support Arrangements
Shadow IT takes many forms and types
1. CUST – customised solution developed by a third-party
2. DEV – personal devices used to access business systems or authenticate access to hosted solutions used for business
3. DIY – end-user computing application developed by the business
4. HOME – organisation data sent to home devices to be worked on
5. MSG – public messaging and data exchange platforms
6. OPEN – open-source software used as a stand-alone solution or incorporated into other solutions
7. OUT – outsourced service solution
8. PROD – software product acquired by the business and implemented on organisation infrastructure
9. PUB – accessing organisation applications and data using public devices or networks
10. STOR – public data storage and exchange platforms
11. SVC – hosted software solution
Uncontrolled shadow IT represents a real risk to organisations. The experience from previous shadow IT examples is that they have resulted in real financial losses. IT architecture can and should take the lead in implementing structures and processes to mitigate risks while taking maximising the benefits of shadow IT.
Capability-based Business Model TransformationIlia Bider
Presentation at Ascendia workshop 2014
Any organization in subject of changes in the environment, or having the desire to improve, needs to change their processes, personnel and their use of resources. Changes, may they be called for by external threats or opportunities or internal strengths or weaknesses, take their departure in an organizations existing capabilities. To support change, there is thus a fundamental need to understand and analyse an organizations capabilities in order to perform changes. In this paper we present an approach to support organizational change by the use of a capability based recursive analysis, and a set of improvement patterns. The recursive analysis is based on resource types, and capability sub-types. We illustrate the approach by using several examples taken from the industry.
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.
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.
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.
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.
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.
IT4IT and DevOps Tools Landscape (2020).Rob Akershoek
Complete overview of the IT management tooling landscape 2020. Key market players / vendors in the IT4IT and DevOps tooling ecosystem. Automate and streamline your end-to-end DevOps tool chain.
An example of a successful proof of conceptETLSolutions
In this presentation we explain how to create a successful proof of concept for software, using a real example from our work in the Oil & Gas industry.
Structured Approach to Solution ArchitectureAlan McSweeney
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.
Introduction to Business Architecture - Part 2Alan McSweeney
The first part is available at: https://www.slideshare.net/alanmcsweeney/introduction-to-business-architecture-part-1.
This material describes conducting a specific business architecture engagement. The engagement process is generic and needs to be adapted to each specific application and use. The engagement is a formal process for gathering information and creating a new business function model based on an analysis of that information.
The objective is to create a realistic and achievable target business architecture to achieve the desired business change.
Business architecture is a structured approach to analysing the operation of an existing business function or entire organisation with a view to improving its operations or developing a new business function, with a strong focus on processes and technology. Business architecture is not about business requirements – it is about business solutions and organisation changes to deliver business objectives.
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.
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.
Shadow IT And The Failure Of IT ArchitectureAlan McSweeney
The continued existence and growth of shadow IT gives IT architecture the opportunity show leadership. IT architecture can be the gateway for business IT solution requirements, from initial solution concept through to solution realisation.
Shadow IT is 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. There are many aspects of shadow IT:
• Shadow Projects
• Shadow Data
• Shadow Sourcing
• Shadow Development
• Shadow Solutions
• Shadow Support Arrangements
Shadow IT takes many forms and types
1. CUST – customised solution developed by a third-party
2. DEV – personal devices used to access business systems or authenticate access to hosted solutions used for business
3. DIY – end-user computing application developed by the business
4. HOME – organisation data sent to home devices to be worked on
5. MSG – public messaging and data exchange platforms
6. OPEN – open-source software used as a stand-alone solution or incorporated into other solutions
7. OUT – outsourced service solution
8. PROD – software product acquired by the business and implemented on organisation infrastructure
9. PUB – accessing organisation applications and data using public devices or networks
10. STOR – public data storage and exchange platforms
11. SVC – hosted software solution
Uncontrolled shadow IT represents a real risk to organisations. The experience from previous shadow IT examples is that they have resulted in real financial losses. IT architecture can and should take the lead in implementing structures and processes to mitigate risks while taking maximising the benefits of shadow IT.
Capability-based Business Model TransformationIlia Bider
Presentation at Ascendia workshop 2014
Any organization in subject of changes in the environment, or having the desire to improve, needs to change their processes, personnel and their use of resources. Changes, may they be called for by external threats or opportunities or internal strengths or weaknesses, take their departure in an organizations existing capabilities. To support change, there is thus a fundamental need to understand and analyse an organizations capabilities in order to perform changes. In this paper we present an approach to support organizational change by the use of a capability based recursive analysis, and a set of improvement patterns. The recursive analysis is based on resource types, and capability sub-types. We illustrate the approach by using several examples taken from the industry.
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.
Advancing Engineering with AI through the Next Generation of Strategic Projec...OnePlan Solutions
In the engineering sector, mastering the intricacies of project management demands innovative solutions. This webinar explores the integration of AI into project planning for engineering, tackling both immediate challenges in planning and execution while also setting the stage for unprecedented efficiency and quality. With a spotlight on practical applications, we’ll explore strategies for harnessing AI to optimize resource distribution, ensure precise time management, and elevate project quality. Discover how adopting a technology-forward approach, exemplified by platforms like OnePlan, can transform project outcomes, enhance team collaboration, and boost overall profitability without sacrificing the high standards engineering projects require.
Chapter 07 of ICt Project Management based on IOE Engineering syllabus. This chapter covers the knowledge on development of project charters, direct and manage project execution, monitor and control project work and more.Provided by Project Management Sir of KU.
The Five Phases of Agile Maturity (Part 2): Phase 3 and 4Cprime
The journey to agile maturity is neither fast nor straightforward. What do you need to know? What challenges might you face? Which tools will best meet your organization where it's at?
Explore what you should expect to see across the five phases of Agile maturity. In part 2 of this series, we will focus on Phase 3 and 4. We'll share valuable advice about negotiating the turns, avoiding roadblocks, and enjoying the ride in your agile maturity journey. Plus, we’ll talk about the optimal tools to support you—enterprise product management software, like Atlassian Jira Align.
Learn:
- Common maturity elements of Phase 3 of agile maturity (The Scaling Agile Organization) and Phase 4 of agile maturity (The Agile Enterprise)
- Challenges you may face in your agile maturity journey and how to overcome them
- How Jira Align’s features and functionality can support scaling
Identification of all areas contributing to problems and determining scope of projects are challenges for many organizations. A method to improve the outcomes can help reduce risk - find out how!
It is focusing on behalf of Digtialleverage Consulting Services providing Business Development Services by using Technologies in an appropriate manner at a right time in right place.This can offer as on-Site or offshore model.
Benefits of Microsoft Enterprise Project Managment Server (EPM) for any Organisation
Demand Management
Resource Management
Schedule Management
Capacity Management
Workflow Management
Security Management
Sabrion has a highly qualified team of retail/manufacturing process experts and IT consultants, supporting both short and long-term needs. Our FastForward implementation methodology to support PLM and Merchandise planning.
Project Management
PMI – Project Management Institute
PMBOK – Project Management Body of Knowledge
Agile – We utilize Agile, Scrum, and Extreme methodologies when appropriate
We are flexible to embrace the methodologies used by our customers an business partners
Retail/Manufacturing Business Process Re – Engineering
As-Is and To-Be Modeling, SIPOC, RACI, Impact Analysis, Standard Operating Procedures
Application Design, Development and Integration
UML – Unified Modeling Language
Open Internet and Standards, HTML5, CSS3, JQuery, Javascript, Web Frameworks
Application Architecture
Application Infrastructure Design – Virtualization, Cloud, Application Servers, Storage, Web DMZ
Global Network Design – LAN, WAN, MPLS, Reverse Proxy, CDN
Deployment Architecture – Dev, QA, Staging, Production
The importance of applying Operational Excellence principles for your business. How to improve your Projects delivery process. Excellentia Project Management Consulting presentation.
Using Earned Value Management Concepts to Improve Commercial Project PerformanceLewisFowlerLLC
Lewis Fowler Principal Consultant Scott Brunton presented this deck at the 2015 Houston PMI Conference & Expo. Scott explores the historical roots of EVM and offers practical advice for implementing EVM practices to maximize the business value of projects.
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.
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.
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.
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.
Describing the Organisation Data LandscapeAlan McSweeney
Outlines an Approach to Describing the Organisation Data Landscape to Assist with Data Transformation Analysis and Planning
The Data Landscape is a representation of the organisation’s data entities and their relationships, interfaces and data flows. Data entities are data asset components that perform data-related functions, from data storage to data transfer and data processing within the Data Landscape.
The objective of developing a Data Landscape model is to define an approach for formally and exactly defining the operation and use of data at a high-level within the organisation and to plan for future changes. It allows the enterprise data fabric to be defined and modelled.
Creating a data landscape view is important as data underpins the operation of information technology solutions and business processes. Data breathes life into solutions as its flows through the organisation. The optimum and most cost-effective design of the data landscape is therefore important. Similarly, solutions that are developed or acquired and deployed on the data landscape
The nature of the organisation data landscape is changing as organisations are undergoing a data transformation.
Solution Architecture Centre Of ExcellenceAlan McSweeney
This is an extract from the book An Introduction to Solution Architecture (https://www.amazon.com/dp/1797567616) that discusses the topic of a Solution Architecture Centre Of Excellence.
The solution architecture function should aspire to be a Solution Architecture Centre Of Excellence (SACOE). This is concerned with developing a mature function that is highly-skilled at solution architecture and design and provides solution and consulting leadership to the organisation.
Developing an SACOE requires vision and resources of both the solution architecture function and information technology management.
The solution architecture function has the capability to develop both the business insight and solution and technology expertise to act as the business/technology authority and be the bridge between the business and technology domains of the organisation.
Solution Architecture and Solution ComplexityAlan McSweeney
This is an extract from the book An Introduction to Solution Architecture (https://www.amazon.com/dp/1797567616) that discusses the topic of solution complexity.
The solution architect cannot design solution in isolation without being aware of the implications of its subsequent delivery. Inherent unnecessary complexity must be avoided. The solution architect does not have control of the wider environment in which the solution will be delivered and that may be a source of additional complexity. But the solution architect can try to influence this by indicating where solution delivery problems may arise due to complexity so mitigation actions can be taken. The complexity factors can be used to assess and select solution options. The goal is, as always, no surprises.
Essentials of Automations: Optimizing FME Workflows with ParametersSafe Software
Are you looking to streamline your workflows and boost your projects’ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, you’re in the right place.
Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part “Essentials of Automation” series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects.
Here’s what you’ll gain:
- Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows.
- Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy.
- Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency.
- Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity.
We’ll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic.
Don’t miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...UiPathCommunity
💥 Speed, accuracy, and scaling – discover the superpowers of GenAI in action with UiPath Document Understanding and Communications Mining™:
See how to accelerate model training and optimize model performance with active learning
Learn about the latest enhancements to out-of-the-box document processing – with little to no training required
Get an exclusive demo of the new family of UiPath LLMs – GenAI models specialized for processing different types of documents and messages
This is a hands-on session specifically designed for automation developers and AI enthusiasts seeking to enhance their knowledge in leveraging the latest intelligent document processing capabilities offered by UiPath.
Speakers:
👨🏫 Andras Palfi, Senior Product Manager, UiPath
👩🏫 Lenka Dulovicova, Product Program Manager, UiPath
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.
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...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.
Connector Corner: Automate dynamic content and events by pushing a buttonDianaGray10
Here is something new! In our next Connector Corner webinar, we will demonstrate how you can use a single workflow to:
Create a campaign using Mailchimp with merge tags/fields
Send an interactive Slack channel message (using buttons)
Have the message received by managers and peers along with a test email for review
But there’s more:
In a second workflow supporting the same use case, you’ll see:
Your campaign sent to target colleagues for approval
If the “Approve” button is clicked, a Jira/Zendesk ticket is created for the marketing design team
But—if the “Reject” button is pushed, colleagues will be alerted via Slack message
Join us to learn more about this new, human-in-the-loop capability, brought to you by Integration Service connectors.
And...
Speakers:
Akshay Agnihotri, Product Manager
Charlie Greenberg, Host
Connector Corner: Automate dynamic content and events by pushing a button
Solution Architecture and Solution Estimation.pdf
1. Solution Architecture and
Solution Estimation
Alan McSweeney
http://ie.linkedin.com/in/alanmcsweeney
https://www.amazon.com/dp/1797567616
2. Solution Architecture and Solution Estimation
• Solution architects 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 estimates
− 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
• These notes describe a solution estimation approach that
can be used to create solution estimates
November 8, 2022 2
3. Why Create Estimates?
• 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
• Estimates are a key input to investment management and
making effective decisions on the portfolio of solutions to
implement
• Enables informed decision-making as part of IT investment
management
November 8, 2022 3
4. What Is Being Estimated?
• The likely cost of the solution
• The duration it will take to implement the solution
• The resources and skills required to realise the solution
• The benefits that will be derived from the successful
implementation and operation of the solution
• The recurring costs associated with its operation,
maintenance, support, administration and other ongoing
activities
• This is repeated for individual solution options and then
across the set of possible solutions be assessed for possible
implementation
November 8, 2022 4
5. Estimates And Investment Management
• Estimates allow
investments in new
solutions to be
prioritised
• Solution cost profile
over time is one
input to the
decision-making
process
November 8, 2022 5
6. Solution Estimation Effort
• 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
November 8, 2022 6
8. Estimation Journey Types
• Initial Detailed and Accurate
Estimates
− Requires detailed and fixed
requirements and solution
specification
− Detailed solution Bill Of
Materials created from
specification
− BOM costed in detail
− Takes a long time and a lot of
resources
• Long well-defined unchanging
solution delivery journey
− Changes can be very expensive
• Delivery journey does not
start until large up-front
effort is expended
• Initial High-Level Estimates
Subsequently Refined and
Expanded
− Initial high-level solution
journey view and estimates
− Frequent course corrections
and changes of direction as
journey progresses and
understanding grows
− Greater uncertainty regarding
the initial course
− Journey starts sooner with less
up-front planning, design and
preparation
• Mirrors an agile solution
delivery process
November 8, 2022 8
9. Continuity From Solution Estimation To Solution
Delivery
• The solution breakdown structure created during the
estimation process will feed into the creation of the work
breakdown structure needed to create a solution delivery
plan
November 8, 2022 9
10. Not All Solution Concepts Become Delivered And
Deployed Solutions
November 8, 2022 10
Concept
• Many solution concepts are not progressed with
• Decisions are made to cancel/defer/merge solutions as factors such as business circumstances and
available resources and finance change
• Estimation process needs to be more accurate as solution assessment proceeds
Analysis
And
Business
Case
Initiate Plan Design Build
Deploy and
Operate
11. What Is Being Estimated?
• There are always many ways to implement a solution concept based
on many factors, such as:
− Degree of automated or manual operations and integration
− Acquire product or custom development
− Comprehensive or limited
− Scalability
− Performance and throughput
− Reliability
− Ease of maintenance
− Degree of automation
− Number of manual handoffs and interventions
− Degree of usability
• To meet business requirements such as:
− Expected life of the solution
− Available budget
− Need to meet business requirements quickly
− Range of functionality needed
November 8, 2022 11
12. Range Of Solution Option Factors
November 8, 2022 12
Dimensions of Solution
Options
Functional
Suitability
Functional
Completeness
Functional
Correctness
Functional
Appropriateness
Enhancement
and Future
Development
Performance
Efficiency
Time Behaviour
Resource
Utilisation
Capacity
Performance
and Throughput
Scalability
Compatibility
Co-existence
Interoperability
Usability
Appropriateness
and
Recognisability
Learnability
Operability
User Error
Protection
User Interface
Aesthetics
Accessibility
Efficiency and
Automation
Reliability
Maturity
Availability
Fault Tolerance
Recoverability
Security
Confidentiality
Integrity
Non-repudiation
Accountability
Authenticity
Maintainability
Modularity
Reusability
Analysability
Modifiability
Testability
Portability
Adaptability
Installability
Replaceability
Data
Data Model
Reporting
Analysis
Data Facilities
Integration
Manual vs.
Automated
Product vs
Custom
Product and
Platform
Options
Custom
Development
13. Range Of Solution Option Factors
• There are many factors to be considered when determining a
solution design
• Each of these factors gives rise to solution options that have
impacts on the cost, time, and resources required to deliver the
solution, the requirements it fulfils and its long-term operation
• In particular, solution options can impact on recurring costs due
to decisions to omit solution components that contribute to
reduced operating resources and associated costs
• Need to tune the solution dial appropriately
November 8, 2022 13
Minimum
Solution
Maximum
Solution
14. Distilling The Solution Option Factors In Whole
Solution Options
November 8, 2022 14
Functional
Completeness
Functional
Correctness
Functional
Appropriateness
Enhancement
and Future
Development
Time Behaviour
Resource
Utilisation
Capacity
Performance
and Throughput
Scalability
Co-existence
Interoperability
Appropriateness
and
Recognisability
Learnability
Operability
User Error
Protection
User Interface
Aesthetics
Accessibility
Efficiency and
Automation
Maturity
Availability
Fault Tolerance
Recoverability
Confidentiality Integrity
Non-repudiation
Accountability
Authenticity
Modularity
Reusability
Analysability
Modifiability
Testability
Adaptability
Installability
Replaceability
Data Model
Reporting
Analysis
Data Facilities
Manual vs.
Automated
Product and
Platform
Options
Custom
Development
15. Range Of Solution Option Factors
• There are many factors that give rise to potentially many
solution options
• One of the roles of the solution architect is to narrow the
solution factors into a small set of realistic, achievable,
cost-effective solution options that will deliver on some or
all of the business requirements
November 8, 2022 15
16. Lots Of Reasons For Poor Quality Estimates
November 8, 2022 16
17. Strategic Misrepresentation
• This is the deliberate, systematic distortion or
misstatement of facts such as costs, time, complexity or
risk in order to get a solution delivery project approved
initiated
− Subsequent solution scope changes are not really changes due to
new functionality requirements being uncovered but knowable
requirements and needs that were previously deliberately ignored
• Do not underestimate the contribution of strategic
misrepresentation to solution scope, budget, functionality
and timeline problems
• Strategic misrepresentation can have a significant impact
on solution estimates
• It is more common that might be believed
November 8, 2022 17
18. November 8, 2022 18
IT Investment Issues
• IT is a key enabler of organisational strategy
• Many organisations do not know exactly how much is spent on IT
• Many organisations cannot accurately characterise IT assets
• In many organisations, IT accounts for 50% or more of capital
expenditure
• IT architecture is perceived as not providing the adaptability that is
needed
• IT is seen as a friction point for change and not enough of an enabler
• Organisations must implement processes for managing IT investment
both for the value they deliver as well as their cost
• There has been significant waste of IT investments and unused IT
systems due to lack of investment validation
− Over 80% of projects do not come close to their original goals of lifecycle costs
− More expensive to implement and/or operate than initially stated
19. November 8, 2022 19
Questions on IT Investments
• Is your organisation’s IT portfolio a manifestation of your
organisation’s mission and strategy?
• Can you identify which IT projects are interdependent with adjacent
people and process initiatives?
• Do you have a rigorous IT investment selection process that is devoid
of emotion and politics?
• Do you account for multiple risk categories - technical, business,
project, customer - when evaluating investment proposals?
• Is IT operating expense in line with organisation growth?
• Can you identify which IT investments contribute to true competitive
advantage or mission achievement?
• Do IT investment decision making methods mesh with the decision
making framework of organisation?
20. November 8, 2022 20
IT Value Management is a Key Topic for IT
71%
62%
52%
45%
40%
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
CEO/CFO Demanding Better Ways To
Demonstrate Value
Find It Difficult To Calculate ROI
Executives Skeptical Of ROI From IT
Metrics Do Not Adequately Capture Business
Value
Do Not Measure Business Value From IT
Investments
• Results of managing IT for business value
− Budget flexibility coupled with strategic IT alignment leads to 50% greater IT
payoffs
− Improving management practices alongside IT investment drives 20% higher IT
yields
21. November 8, 2022 21
IT Investment Core Requirements
• Determine the scale, scope, and sources of funding for IT
• Assign financial resources to competing activities within
the IT portfolio
• Establish a balance between capital expenditure (new
projects) and operating expenditure (running systems
delivered by past projects)
• Optimise the total cost of ownership
• Manage IT portfolios for value and not just cost
• IT needs to implement a process for justifying its costs and
be seen to be taking these steps
22. November 8, 2022 22
IT Investment Management
• Aligns IT Investments to organisation strategy (scoring)
• Prioritises investments (ranking)
• Provides strategic criteria for investment analysis
• Conduct annual IT portfolio management reviews
• Provides recommendation to stop, slow, maintain or
accelerate program funding
• Identifies redundant/inefficient systems
• Integrates IT architectures within investments
• Ensures compliance with funding standards
23. Estimate Accuracy
Move from initial rough order/very rough order
of magnitude estimates to more accurate
Not all proposed solutions progress through all
stages and require detailed and accurate
estimates
November 8, 2022 23
Move From Initial Solution Concept To Delivery
Estimates need to be more accurate as the
implementation of the solution becomes more
likely
More accurate estimates requires more accurate
information and more effort
24. Estimation Approaches
November 8, 2022 24
Bottom Up – Assemble
Estimates From Detailed
Work Breakdown
Top Down – Assemble
Estimates Similar Solutions
And Experiences
25. What Does An Estimate Consist Of?
November 8, 2022 25
Effort
Roles and Skills
Additional Resources
Duration/Time
Cost
Allowance For
Uncertainty/
Contingency
+
Initial and Ongoing
26. Estimation Range
• 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
November 8, 2022 26
27. Two Aspects To Estimates
Need to create
estimates for
both
implementation
and operation
and for the
benefits and
saving that will
be achieved and
when they will
be achieved
November 8, 2022 27
Implementation
And Operation
Estimates
Savings And
Benefits
Estimates
28. Solution Estimation Template
• This presents an approach to and associated template for
solution estimation that includes the activities outlined in
these notes
• A structured and repeatable process gives consistent
results
• A library of estimates can be created and maintained and
used as a reference to refine the estimation process and
improve its accuracy and precision
November 8, 2022 28
29. Overview Of Estimation Approach
• The core solution breakdown structure and their associated
build estimates are at the core of the estimate process
• Other estimates are effectively uplifts of these core estimates
November 8, 2022 29
Core Solution
Build
Estimates
Other Solution Delivery
Phases Estimates
Project Management Overhead Estimates
Solution
Operation
Risk and Contingency Overhead Estimates
Complexity Overhead Estimates
1
2
3 4
5
6
30. Overview Of Estimation Approach
• This gives rise to a set of activities:
− 0. Define Solution Overview
− 1. Create Solution Component Work Breakdown
− 2. Create Estimates For Solution Components
− 3. Estimate Solution Delivery Complexity and Impacts
− 4. Create Estimates For Non-Build Project Phases
− 5. Estimate Solution Delivery Risks
− 6. Uplift Estimates With Risk, Contingency And Complexity Factors
− 7. Estimate Delivery Size And Duration
− 8. Estimate Benefits
− 9. Estimate Resource Costs
− 10. Create Multi-Year Cost Estimates
− 11. Create Solution Estimate Overview Dashboard
November 8, 2022 30
31. 0. Define Solution Overview
• Enter solution
overview details
including
− Number of years for
which the estimate is to
be created
− The annual rate of
increase to be applied
to estimates
November 8, 2022 31
33. Solution Component Breakdown Structure
• The start of any solution estimation is an effective knowledge of
the solution component breakdown
• This provides a basis for an informed estimates
• The initial solution component breakdown does not have to be
exact – it can be refined as more exact estimates are required
• The solution component breakdown provides knowledge of the
solution structure
• The solution breakdown structure is effectively a high-level
solution design
• The precise nature of the ultimate solution may not be known
or agreed at the initial estimation stage
• There may be several solution options that need to be
estimated
November 8, 2022 33
34. Solution Component Types
• Any solution will consist of a number of components of a range
of component types
November 8, 2022 34
35. Solution Component Structure And Integrations
• The solution architect can create a logical solution component view (and their
options) in order to create the solution breakdown structure
November 8, 2022 35
Solution
Central Data
Store
Solution
Central
Application
Component
Solution API
Solution
Central
Infrastructure
Solution
Hosted
Infrastructure
Solution
Internal
Consumers
Solution
External
Private
Consumers
Solution
Hosted Data
Store
Solution
Hosted
Application
Component
Solution
Hosted
Analytics
Access and
Security
Infrastructure
Central To
Hosting
Facility
Connectivity
Solution
External Public
Consumers
Solution
Mobile App
36. Solution Components And Solution Component Types
November 8, 2022 36
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Component
Changes to Existing Systems
New Custom Developed
Applications
Acquired and Customised Software
Products
System Integrations/ Data
Transfers/ Exchanges
Reporting and Analysis Facilities
Sets of Installation and
Implementation Services
Information Storage Facilities
Existing Data Conversions/
Migrations
New Data Loads
Central, Distributed and
Communications Infrastructure
Cutover/ Transfer to Production And
Support
Operational Functions and
Processes
Parallel Runs
Enhanced Support/ Hypercare
Sets of Maintenance, Service
Management and Support Services
Application Hosting and
Management Services
Changes to Existing Business
Processes
New Business Processes
Organisational Changes, Knowledge
Management
Training and Documentation
37. Solution Component Types And Estimates
• Some solution component types give rise to effort which in turn
give rise to cost
• Other solution component types give rise to costs associated
with the acquisition of products and/or services
• This cost and effort profile will affect the solution estimates
November 8, 2022 37
Component Type
Components
That Give Rise to
Effort
Components
That Give Rise to
Cost
Initial and
Recurring
Initial Cost
Ongoing
Operating and
Usage Cost
Recurring Service
Cost
38. Solution Components Classes And Types
November 8, 2022 38
Solution Components
Time-Bounded Delivery Entity
Types
Sets of Installation and
Implementation Services
Existing Data Conversions/
Migrations
New Data Loads
Parallel Runs
Enhanced Support/ Hypercare
Enduring Operational
Technology Entity Types
Changes to Existing Systems
New Custom Developed
Applications
Acquired and Customised Software
Products
System Integrations/ Data
Transfers/ Exchanges
Reporting and Analysis Facilities
Information Storage Facilities
Central, Distributed and
Communications Infrastructure
Application Hosting and
Management Services
Enduring Process, Procedure
and Structural Entity Types
Cutover/ Transfer to Production And
Support
Operational Functions and
Processes
Sets of Maintenance, Service
Management and Support Services
Changes to Existing Business
Processes
New Business Processes
Organisational Changes, Knowledge
Management
Training and Documentation
39. Solution Component Types And Estimates
• This shows
the cost
profile
classification
of solution
component
types
November 8, 2022 39
Component Type Cost Profile
Changes to Existing Systems Effort
New Custom Developed Applications Effort
Acquired and Customised Software Products Product and/or Service Cost
System Integrations/ Data Transfers/ Exchanges Effort
Reporting and Analysis Facilities Effort
Sets of Installation and Implementation Services Effort
Information Storage Facilities Product and/or Service Cost
Existing Data Conversions/ Migrations Effort
New Data Loads Effort
Central, Distributed and Communications Infrastructure Product and/or Service Cost
Cutover/ Transfer to Production And Support Effort
Operational Functions and Processes Effort
Parallel Runs Effort
Enhanced Support/ Hypercare Effort
Sets of Maintenance, Service Management and Support Services Product and/or Service Cost
Application Hosting and Management Services Product and/or Service Cost
Changes to Existing Business Processes Effort
New Business Processes Effort
Organisational Changes, Knowledge Management Effort
Training and Documentation Effort
41. Solution Component Estimates
• Two types of components and their estimates:
1. Effort
2. Product/service cost
November 8, 2022 41
42. Sample Solution Effort Component Estimates
• This shows a
sample
solution
component
effort
breakdown
based on the
solution types
• Components
associated
with
component
types that
give rise to
cost rather
than effort
are left blank
here and
completed
elsewhere in
the template
November 8, 2022 42
43. Sample Solution Effort Component Estimates
• The solution architect can co-ordinate the creation of
effort estimates for the solution components
• Detailed component-specific knowledge may reside
elsewhere
• The solution architect can sense-check these estimates
November 8, 2022 43
44. Sample Solution Effort Component Estimates
• Identify the number of components of each type
• Define an optional complexity for each solution component
• Identify a low and high estimate effort range for each
component
− Solution component complexity can be used to identify the
specific low and high estimate effort range for each component
November 8, 2022 44
46. Product/Service Solution Component Estimates
• Each vendor will price their product/service component
differently
− Initial cost and recurring maintenance/support charge
− Recurring charge
− Each product/service component will have a number of unit types and
unit numbers
• Estimation template needs to be able to capture this complexity
• Product/service component types include:
− Acquired and Customised Software Products
− Information Storage Facilities
− Central, Distributed and Communications Infrastructure
− Sets of Maintenance, Service Management and Support Services
− Application Hosting and Management Services
November 8, 2022 46
47. Product/Service Solution Component Costing
Example
• Solution component type of
Acquired and Customised
Software Products
• Three Unit Types in this
example
− Production Server License
− User Licenses
− Development and Test
Environment
• Select Cost Type
− Initial and Annual
Maintenance
− Recurring
• For a cost type of Initial and
Annual Maintenance define
when the maintenance cost
starts;
− Year 1 or Year 2
• Enter low and high
estimates for each Unit Type
of Component Type
November 8, 2022 47
48. Product/Service Solution Component Costing
Example
• Solution component type Acquired and Customised
Software Products called New Product 1
• Three unit types
− Production Server
• Low and high estimates of 4 and 6 for Production Server with an estimated
unit cost of €50,000
• Maintenance charge of 12% unit acquisition cost starts in the first year
− User Licenses
• Low and high estimates of 200 and 300 for User Licenses with an estimated
unit cost of €250
• Maintenance charge of 12% unit acquisition cost starts in the first year
− Development and Test Environment
• Low and high estimates of 2 and 4 for Development and Test Environment
• with an estimated unit cost of €15,000
• Maintenance charge of 12% unit acquisition cost starts in the first year
November 8, 2022 48
49. Product/Service Solution Component Costing
Example
• Production Server
− Low: 4 x €50,000 + 12 % x €50,000 = €224,000 Year 1 cost and €24,000 Year 2
and subsequent cost
− High: 6 x €50,000 + 12 % x €50,000 = €336,000 Year 1 cost and €36,000 Year
2 and subsequent cost
• User Licenses
− Low: 200 x €50,000 + 12 % x €250 = €56,000 Year 1 cost and €6,000Year 2
and subsequent cost
− High: 300 x €50,000 + 12 % x €50,000 = €84,000 Year 1 cost and €9,000 Year
2 and subsequent cost
• Development and Test Environment
− Low: 2 x €50,000 + 12 % x €50,000 = €33,600 Year 1 cost and €3,600 Year 2
and subsequent cost
− High: 4 x €50,000 + 12 % x €50,000 = €67,200 Year 1 cost and €7,200 Year 2
and subsequent cost
• Total estimates for this solution component
− Low: €313,600 Year 1 cost and €33,600 Year 2 and subsequent cost
− High: €487,200 Year 1 cost and €52,200 Year 2 and subsequent cost
November 8, 2022 49
51. Complexity And Risk
• Complexity refers to uncertainty regarding the set of
information on solution components that comprise the solution
• Risks refer to negative events relating to the overall solution
delivery activity that have a probability of occurrence and that,
if they occur, will have a negative impact on delivery in terms of
increased time and cost
• Proposed solution estimation approach and template handles
both complexity and risk as separate estimation uplift factors
that are applied to solution component estimates
• Complexity and risk are different but the individua factors
leading to their calculation overlap – it is important not to
double-count and apply uplift twice
November 8, 2022 51
52. Solution Complexity Estimation
• The complexity of the solution can affect its
implementabilty, both directly and indirectly
− Directly
• Complex solutions are inherently problematic because of intrinsic
uncertainty
− Indirectly
• Apparent or actual complexity can reflect a lack of knowledge and certainty
about either or both the knowledge about the problem or the solution
• This lack of knowledge will affect the accuracy of the estimation process and
the estimates it creates
• This uncertainty is handled by adding an allowance of
additional solution delivery budget that can be expended
to develop resolutions to challenges that arise when risks
and complexities become actual
November 8, 2022 52
53. Solution Complexity Factors
• The potential complexity of a solution can be assessed
• Any assessment is inherently and multiply subjective:
− Selection of complexity factors to be used for assessment
− Assignment of weighting or importance to complexity factors
− Assignment of score to each complexity factor
• Groups of complexity factors used in the approach are:
− Operational Factors
− Technical Factors
− Business Factors
− Product and Service Factors
− Project Factors
November 8, 2022 53
54. Solution Complexity Factors
Operational Factors
Operational Security
Requirements
Confidentiality Of Data Being
Processed
Operational Performance And
Throughput Requirements
Operational Reliability And
Availability Requirements
Amount Of On-Premises
Infrastructure Required
Volume Of Data Being
Processed
Number Of Transactions To Be
Processed
Number Of Different Types Of
Transactions To Be Processed
Number Of Internal Solution
Consumers
Number Of External Solution
Consumers
Technical Factors
Number Of Technologies
Included In The Overall
Solution
Number Of Solution
Components
Number Of Solutions
Integrations And Interfaces
Number Of Application Tiers
Technologies Already Part Of
The Organisation’s Enterprise
Architecture
Lack of Availability Of Skills
And Experience In
Technologies
Amount Of Custom
Development
Development Platform
Productivity
Amount And Complexity Of
Data To Be Loaded Or
Migrated
Reuse Of Existing Custom
Components
Business Factors
Business Resources and
Personnel Required
Number Of Business Functions
Or Areas That Will Use The
Solution
Public Use of the Solution
Number And Complexity Of
Underlying Business Processes
Regulatory And/Or
Compliance Dimension to
Solution
Lack of Familiarity Of The IT
Function With The Business
Functions Or Areas
Lack of Availability Of Business
Resources To Work On The
Solution
Number Of Locations Of
Business Functions
Number Of Existing Solution
Components Being Replaced
Organisation Change
Requirements
Product and Service
Factors
Number Of Products and
Services Required To Deliver
The Solution
Number Of Separate Suppliers
Involved In The Delivery Of
The Product(s) and Service(s)
Immaturity Of The Product(s)
and Service(s)
Lack of Supplier Proven Skills
And Experience In
Implementing Products and
Services
Products and Services Are
Being Provided By Suppliers
New To The Organisation
Number Of Supplier Offshore
Locations Involved In The
Delivery Of The Product(s) and
Service(s)
Degree Of Configuration Of
Product(s) and Service(s)
Degree Of Customisation Of
The Of Product(s) and
Service(s)
Number Of Personnel From
Supplier Involved In The
Product and Service Delivery
Nature Of Outsourcing
Relationship, If Applicable The
Delivery Of The Product(s) and
Service(s)
Amount Of New Technology
Introduced By The Product(s)
and Service(s)
Project Factors
Fixed Project Implementation
Deadline
Expected Project Duration
Overall Project Size
Number Of Outsourcing
Arrangements Included In The
Overall Solution
Number Of Externally Hosted
Components Included In The
Overall Solution
Size Of Implementation
Project Team
Multiple Language
Requirements
Number Of Jurisdictions In
Which The Solution Will
Operate
Skill and Experience
Factors
Lack of Project Manager Skills
And Experience
Lack of Implementation Team
Skills And Experience
November 8, 2022 54
55. Solution Complexity Scoring
• Complexity is scored in two ways:
− Weighting is assigned to each factor with a value assigned to each
weight:
• Very Low – 0.5
• Low – 0.75
• Medium – 1
• High – 1.25
• Very High – 1.5
− Complexity factor is then scored in a range such as 0 to 10
− Individual factor complexity is then Weighting x Score:
• Very Low x 5 = 2.5
• Very High x 8 = 12
• Overall solution complexity factor is the sum of the individual
complexity factors
• Need to be able to apply the complexity uplift factor to initial
solution estimates accurately
November 8, 2022 55
56. Solution Complexity Scoring
• If a complexity factor is not applicable, it can be assigned a
score of zero
November 8, 2022 56
Assign Importance
to Complexity
Factor
Assign Rating to
Complexity Factor
Weighted
Complexity =
Importance x Score
57. Sample Complexity Model
• 51 complexity factors in this model
• Average weighted score = 51 x 5 x 1 (Medium Weight) =
255
• Maximum weighted score = 51 x 10 x 1.5 (Very High
Weight) = 765
• The complexity distribution is not symmetric about the
mean
November 8, 2022 57
58. Sample Complexity Score
• This sample
assessment
leads to a
complexity
score of 306.25
• This will result
in the initial
solution
component
estimates being
increased by
between
13.30% and
28.70%
November 8, 2022 58
59. Sample Solution Complexity
• A low and high
complexity range
uplift is calculated
for the solution
being estimated
based on the
complexity model
November 8, 2022 59
60. Determining Overall Solution Complexity Factor
• Complexity model with
low complexity scores will
result in the estimated
effort being reduced
• Complexity is not
symmetric – complexity
can increase more than it
can decrease
• The application of a
complexity factor to an
initial estimate is one-
sided
− The estimated efforts for
simple solutions are not
uplifted but are also not
reduced
− The estimated efforts for
complex solution are
uplifted
November 8, 2022 60
Non-Symmetric or Heavy-Tailed Complexity Distribution
One-Sided Non-Symmetric Complexity Distribution
61. Complexity Assessment Uplift Factors
• Initial solution
component estimates
are uplifted by the
complexity factor
associated with the
complexity score
• There is a low-high
complexity uplift range
• Maximum complexity
uplift multiplier of 2
November 8, 2022 61
Weighted
Complexity
Score
Raw Estimate
Uplift Factor –
Low
Raw Estimate
Uplift Factor –
High
255 1 1.000
285 1.078 1.155
315 1.155 1.305
345 1.231 1.444
375 1.305 1.567
405 1.376 1.673
435 1.444 1.761
465 1.507 1.830
495 1.567 1.883
525 1.622 1.922
555 1.673 1.950
585 1.719 1.969
615 1.761 1.981
645 1.798 1.989
675 1.83 1.994
705 1.859 1.997
735 1.883 1.998
765 1.904 1.999
63. Project Phases Use For Estimation
• The estimation approach uses a set of generic project phases
• These are then mapped to specific project activities
• Solution delivery management and support is an overhead that is then
prorated across these activities
November 8, 2022 63
Concept
Analysis and
Design
Plan Initiate
Implement
and Build
Test Deploy
Transition to
Production
and Close
1. Business Case, Solution Concept/
Requirements Definition
2. Analysis
3. Solution Architecture and Design
4. Design Review and Approval
5. Planning
6. Initiation and
Mobilisation
7. Implementation Configuration and
Preparation
8. Solution Build
9. Solution Test
10. Deployment,
Business Readiness
and Organisation
Change
11. Service Design, Introduction,
Transition and Management
64. Mapping Project Phases To Estimation Activities
November 8, 2022 64
Concept
Analysis and Design
Plan
Initiate
Implement and Build
Test
Deploy
Transition to
Production and Close
Business Case, Solution Concept/ Requirements
Definition
Analysis
Solution Architecture and Design
Design Review and Approval
Planning
Initiation and Mobilisation
Implementation Configuration and Preparation
Solution Build
Solution Test
Deployment, Business Readiness and
Organisation Change
Service Design, Introduction, Transition and
Management
Ongoing Solution Operation
Project Management
PMO Support
Prorate
65. Project Phases And Activities
• Three group of estimation activities
− Solution Delivery
1. Business Case, Solution Concept/ Requirements Definition
2. Analysis
3. Solution Architecture and Design
4. Design Review and Approval
5. Planning
6. Initiation and Mobilisation
7. Implementation Configuration and Preparation
8. Solution Build
9. Solution Test
10. Deployment, Business Readiness and Organisation Change
11. Service Design, Introduction, Transition and Management
− Solution Delivery Management
1. Project Management
2. PMO Support
− Operations
1. Ongoing Solution Operation
November 8, 2022 65
66. Project Phases And Activities
• Solution Build activity is used as the basis for estimates for
other activities
• This is taken from the previously created estimates of the
solution components
• The additional activities are expressed as a percentage of
the Solution Build activity
November 8, 2022 66
67. Project Phases And Activities
November 8, 2022 67
Previously Created Low and High
Solution Component Implementation
Estimates Carried Here
Low and High Percentage Estimates
Entered for Other Activities
Low and High Range of All Solution
Delivery Activities
68. Project Phases And Activities
• This shows sample low and
high percentages assigned
to each of the activity
• In this example, the 100%
that represents the solution
component
implementation effort is
uplifted to a range of 185%
to 208% to represent the
complete solution design,
delivery and deployment
effort
• This excludes product and
service costs which are
estimated separately
November 8, 2022 68
Solution Delivery Activity Low High
Business Case, Solution Concept/
Requirements Definition, Rough Order of
Magnitude Estimate
2% 3%
Analysis 4% 5%
Solution Architecture and Design 4% 5%
Design Review and Approval 2% 2%
Planning 9% 10%
Initiation and Mobilisation 3% 3%
Implementation Configuration and
Preparation
3% 3%
Solution Build 100% 100%
Solution Test 35% 45%
Project Management 12% 15%
PMO Support 2% 3%
Deployment, Business Readiness and
Organisation Change
6% 9%
Service Design, Introduction, Transition
and Management
3% 5%
Ongoing Solution Operation 15% 25%
Effort Total (Excluding Operation) 185% 208%
69. Solution Delivery And Deployment Activities Profile
• Expressing the solution delivery and deployment activities as a
proportion of the core solution build gives rise to a solution
resource profile
November 8, 2022 69
71. Risk And Contingency Estimation
• The estimation template takes the traditional approach to
risk estimation
• Each risk is assigned a probability range representing an
assessment of the likelihood of it occurring that is assigned
a percentage
• Each risk is assigned a impact range representing an
assessment of impact should it occur that is assigned a
percentage
• A risk score is calculated as probability percentage x impact
• A risk rating is calculated as probability x impact
November 8, 2022 71
72. Risk Rating Probability
• In this approach, there are eight risk probability bands
• These are assigned a risk probability percentage and a
score
November 8, 2022 72
Risk Rating Probability Risk Probability
Assigned
Percentage
Risk Probability
Assigned Score
None/Circumvented 0.00% 0
Very Low 1.00% 1
Low 6.00% 2
Medium 17.00% 3
Quite Likely 20.00% 4
High 25.00% 5
Very High 40.00% 6
Almost Certain 65.00% 7
73. Risk Impact Probability
• In this approach, there are six risk impact bands
• These are assigned a risk impact percentage and a score
November 8, 2022 73
Risk Impact Probability Risk Impact
Assigned
Percentage
Risk Impact
Assigned Score
None/Circumvented 0.00% 0
Very Low 1.00% 1
Low 6.00% 2
Medium 17.00% 3
High 25.00% 4
Very High 35.00% 5
74. Risk Score
• Risk Score = Risk Rating Probability % x Risk Impact Probability %
November 8, 2022 74
None/
Circumvented
Very Low Low Medium High Very High
None/Circumvented 0.00% 0.00% 0.00% 0.00% 0.00% 0.00%
Very Low 0.00% 0.01% 0.06% 0.17% 0.25% 0.35%
Low 0.00% 0.06% 0.36% 1.02% 1.50% 2.10%
Medium 0.00% 0.17% 1.02% 2.89% 4.25% 5.95%
Quite Likely 0.00% 0.20% 1.20% 3.40% 5.00% 7.00%
High 0.00% 0.25% 1.50% 4.25% 6.25% 8.75%
Very High 0.00% 0.40% 2.40% 6.80% 10.00% 14.00%
Almost Certain 0.00% 0.65% 3.90% 11.05% 16.25% 22.75%
75. Risk Impact
• Risk Impact = Risk Rating Score x Risk Impact Score
November 8, 2022 75
None/
Circumvented
Very Low Low Medium High Very High
None/Circumvented 0 0 0 0 0 0
Very Low 0 1 2 3 4 5
Low 0 2 4 6 8 10
Medium 0 3 6 9 12 15
Quite Likely 0 4 8 12 16 20
High 0 5 10 15 20 25
Very High 0 6 12 18 24 30
Almost Certain 0 7 14 21 28 35
76. Risk Data Entry And Calculation
November 8, 2022 76
Select Risk
Probability Rating
Select Risk Impact
Rating
Risk Score
Calculated
Risk Rating
Calculated
Number of Risks
Identified
Total Risk
Score
Total Risk
Rating
77. 6. Uplift Estimates With Risk, Contingency And
Complexity Factors
November 8, 2022 77
78. Uplift Estimates With Risk, Contingency And
Complexity Factors
November 8, 2022 78
Risk and Contingency Uplift
Applied to Base Estimates
Complexity Uplift Applied to
Uplifted Risk and Contingency
Uplift Estimates
Total Delivery Estimate Range
After Risk and Contingency
Uplift
Total Delivery Estimate Range
Complexity Uplift Applied to
Uplifted Risk and Contingency
Uplift Estimates
79. Uplift Estimates With Risk, Contingency And
Complexity Factors
• In this example, the
initial effort estimate
range of 2,324 - 3,458 is
uplifted to a range of
3,065 - 5,181 to provide
an allowance of
resources to handle
delivery challenges
relating to uncertainty
November 8, 2022 79
81. Estimate Delivery Size And Duration
• The previous resource estimates need to be translated into
delivery option based on the previously estimated solution
delivery activities
• The solution delivery phases represent temporal activities
• There are several ways in which the solution delivery can
be organised based on the resources allocated
• Estimation model uses three approaches
1. Resources allocated by phase to determine phase elapsed time
2. Fixed duration
3. Square root – uses the square root of the estimated effort
months
November 8, 2022 81
82. Estimate Delivery Size And Duration
November 8, 2022 82
Concept
Analysis and Design
Plan
Initiate
Implement and Build
Test
Deploy
Transition to
Production and Close
Business Case, Solution Concept/ Requirements
Definition
Analysis
Solution Architecture and Design
Design Review and Approval
Planning
Initiation and Mobilisation
Implementation Configuration and Preparation
Solution Build
Solution Test
Deployment, Business Readiness and
Organisation Change
Service Design, Introduction, Transition and
Management
Ongoing Solution Operation
Project Management
PMO Support
Solution Delivery Activities
Solution Delivery Phases
83. Estimate Delivery Size And Duration
November 8, 2022 83
Solution Delivery Activities
Mapped to Delivery Phases with
Management Overhead Prorated
Available Personnel
By Phase Entered
Elapsed Months
by Phase
Calculated
Elapsed Time
Estimates for Fixed
Duration Option
Calculated
Elapsed Resources
Estimates for Fixed
Duration Option
Calculated
Enter Fixed
Duration in Months
Estimated Elapsed
Months for Allocated
Personnel Option
Estimated Personnel
for Fixed Duration
Option
Estimated Elapsed
Months and Resources
for Square Root Option
85. Estimate Benefits
• The implementation of new solutions should lead to
benefits
• Benefits should be able to be expressed in financial terms
• The cost of the solution implementation and operation
should be offset by any expected benefits to create a net
cost
November 8, 2022 85
88. Estimate Resource Costs
• Solution delivery components that require resources will have a
cost that is based on the profile of resources and their
individual involvement
• Solution delivery resource profile will depend on the solution
costs
− Custom development compared to product(s)
− Use of internal compared to external resources
• Two estimation approaches
− Simple – define the resource role cost and involvement across the entire
solution delivery set of activities
− Complex – define the resource role cost and involvement by individual
delivery phase
• Create average/blended rate that can be used for cost
estimation
November 8, 2022 88
89. Estimate Resource Costs – Simple Approach
November 8, 2022 89
Define Roles
Define Role Costs
Average Rate Across
All Roles and
Involvement
Define Role
Involvement
Across Entire
Project
91. Multi-Year Cost Estimates
• Multi-year
cost
estimates
bring all the
previously
entered
information
together into
a complete
delivery and
operation
view
November 8, 2022 91
When Solution Delivery Stops,
Previously Estimated Solution
Operation Costs Are Applied,
Prorated For the First Year
Costs For Second and
Subsequent Years Are
Increased by Previously
Entered Rate
92. Multi-Year Cost Estimates
• There will be some variation across estimated costs
because of slower or faster solution implementation and
the start of solution operation
November 8, 2022 92
94. Solution Estimation Overview Dashboard
• The previously
entered and
calculated
estimation
information can be
used to create a
solution estimation
dashboard
• Dashboards can be
created for each
solution option and
for the portfolio of
solutions being
evaluated
November 8, 2022 94
95. Errors In Estimates
• The estimation process has the potential for multiple
errors along the estimation process
− Errors in number and type of components
− Errors in component delivery estimates
− Errors in component acquisition costs
− Errors in resource estimates
− Errors in resource cost estimates
− Errors in complexity estimates
− Errors in risk estimates
• The errors will accumulate and be magnified throughout
the estimation process
November 8, 2022 95
96. Errors In Estimates
• Estimation errors will always exist
• There will always be a trade-off between speed and accuracy of estimates
November 8, 2022 96
Risk Estimates Errors
Complexity Estimates Errors
Resource Cost Estimates Errors
Resource Estimates Errors
Component Acquisition Cost
Estimates Errors
Component Delivery
Estimates Errors
Component
Identification
Errors
97. Errors In Estimates
• Estimates will necessarily be inaccurate and subject to
change when initial, high-level estimates are being created
• Risk, contingency and complexity factors can be adjusted
to reflect this early stage estimation uncertainty
November 8, 2022 97
98. Amount Of Data Required For Estimation
• The more data you enter, the greater the opportunity for errors as mistakes can
accumulate
• In the sample estimation template data entry is required at multiple stages with
corresponding chances of errors
− Overview – annual rate of increase
− Solution Component Work Breakdown – wrong set of components identified, solution too
complex, solution not sufficiently complex
− Estimates For Solution Components – estimates are not accurate
− Solution Delivery Complexity – under or over estimate
− Estimates For Non-Build Project Phases – incorrect costs identified
− Solution Delivery Risks – risks not correctly identified or probabilities or impacts wrong
− Benefits – under or over estimate
− Resource Costs – under or over estimate
• Numbers can give the illusion of accuracy (free from errors) and precision (measure
of exactness) while being very wrong
• Be aware of the deception and false comfort of numbers
• Always check and recheck your estimates and have different people perform the
same estimation task
November 8, 2022 98
99. Small Errors Accumulate
• In these examples, the high-
low variation for
accumulated error rates can
be:
− 3% error rate - 48%
− 4% error rate - 65%
− 5% error rate - 81%
− 6% error rate - 98%
− 7% error rate - 116%
• For example, a single error
rate of plus or minus 3%
multiplied 8 times means the
variation between the lowest
and highest value will 48% -
from plus 26% to minus 24%
November 8, 2022 99
101. Wider Context of Solution Estimation
• Solution estimation exists in a wider context
November 8, 2022 101
Solution
Solution
Option 1
Solution
Option 2
Solution
Option 3
Solution
Solution
Option 1
Solution
Option 2
Solution
Option 3
Solution
Solution
Option 1
Solution
Option 2
Solution
Option 3
Solution
Solution
Option 1
Solution
Option 2
Solution
Option 3
Individual Solution
and Its Options
Portfolio of Solutions
and Their Options
IT Investment and Value
Management and Control
and Business Strategy and
Context
102. November 8, 2022 102
IT Investment And Value Management And Control
• IT Investment And Value Management And Control is a systematic
process for deciding on IT investments in new systems
and maintaining and operating existing technology solutions
• It is a process for effective decision-making that ensures IT
investments integrate strategic planning, budgeting, procurement,
and the management of IT in support of the organisation’s needs
− Determines if a given investment in IT is justified
− Ensures IT investment decisions support the needs of the organisation, minmise
risks and maximise returns throughout the investment lifecycle
• It is a structured process for managing the risks and returns
associated with IT investments
• It should ensure that IT investments are implemented at acceptable
costs, within reasonable and expected timeframes, and contribute to
tangible, observable improvements in organisation performance
• An effective estimation process and supporting toolsets is an
important part of overall IT investment management
103. November 8, 2022 103
IT Investment Management Control Function
Responsibilities
IT Investment
And Value
Management
And Control
Technical
Scope
Management
Technical
Requirements
Management
Progress
Reporting and
Management
Risk
Management
Scope, Cost
and Schedule
Management
Earned Value
Management
Portfolio
Management
104. November 8, 2022 104
Portfolio Management
• Portfolio Management is an approach typically combined with a set
of tools for identifying, diagnosing, controlling, and increasing the
aggregate return on investments at a given level of risk tolerance
• Based on the management principle that any set of investments
requires proactive management to maximise value while minimising
risk
• IT portfolio management takes advantage of an integrated set of IT
management processes, techniques, and tools that assist decision
makers in analysing, selecting, evaluating, and controlling an optimal
set of investments
• Properly executed IT portfolio management delivers the benefits of
balancing supply and demand of IT resources (financial and non-
financial), eliminating redundancy, and enabling better alignment
with strategic goals
105. November 8, 2022 105
Earned Value Management
• Earned Value Management (EVM) is a project management metric
that integrates the technical scope of work with schedule and cost
elements for investment planning and control
• Compares the value of work accomplished in a given period with the
value of the work expected in that period
• Differences in expectations are measured in both cost and schedule
variances
• Use EVM in performance-based management systems
• Management of a cost estimate involves continually updating the
estimate with actual data as they become available (EVM) revising
the estimate to reflect changes and analysing differences between
estimated and actual costs
106. November 8, 2022 106
Cost Estimation Best Practices Checklist
• The cost estimate type is clearly defined and is appropriate
for its purpose
• All applicable program costs have been estimated,
including all life-cycle costs
• The cost estimate is independent of funding source
• An affordability analysis has been performed at the agency
level to see how the project fits within the overall portfolio
• The estimate is updated as actual costs become available
from the EVM system or as requirements change
• Post-mortems and lessons learned exercises are
continually documented as information becomes available
107. November 8, 2022 107
Formal Solution Estimation Process
Step 1:
Define the
Purpose of
the Estimate
Step 2:
Develop the
Estimating
Plan
Step 3:
Define the
Project
Step 4:
Determine
the
Estimating
Approach
Step 5:
Identify
Ground Rules
and
Assumptions
Step 6:
Obtain Data
Step 7:
Develop
Point
Estimate
Step 8:
Conduct
Sensitivity
Analysis
Step 9:
Conduct Risk
and
Uncertainty
Analysis
Step 10:
Document
the Estimate
Step 11:
Present
Estimate for
Approval
Step 12:
Update
Estimate to
Reflect
Actual Costs
and Changes
Initiation and Research
The audience, what is
being estimated and why
It is being estimated are
very importance
Assessment
Cost assessment steps
are iterative and can be
accomplished in varying
order or concurrently
Analysis
The confidence in the
point or range of the
estimate is crucial to the
decision maker
Presentation
Documentation and
presentation can make or
break a cost estimating
decision outcome
108. November 8, 2022 108
Formal Solution Estimation Process
• A formal solution estimation process encapsulates the
previously described structured process and associated
template and provides a wider business and investment
context
• Each of the 12 steps is important for ensuring that high-
quality cost estimates are developed and delivered in time
to support important decisions
109. November 8, 2022 109
Cost Estimating Process
• Step 1: Define the Purpose of the Estimate
− Determine the estimate’s purpose
− Determine the level of detail required
− Determine who will receive the estimate
− Determine the overall scope of the estimate
• Step 2: Develop the Estimating Plan
− Determine the cost estimating team
− Outline the cost estimating approach
− Develop the estimate timeline
− Determine who will do the independent cost estimate
− Develop the schedule
110. November 8, 2022 110
Cost Estimating Process
• Step 3: Define the Project
− Identify in a technical baseline description document
− The purpose of the project
− Its system and performance characteristics
− Any technology implications
− All system configurations
− project acquisition schedule
− Acquisition strategy;
− Relationship to other existing systems
− Support (manpower, training, etc.) and security needs
− Risks
− Assumptions
− System quantities for development, test, and production
− Deployment and maintenance plans;
− Predecessor or similar legacy systems
• Step 4: Determine the Estimating Approach
− Define work breakdown structure (WBS) and describe each element
− Choose the estimating method best suited for each WBS element
− Identify potential cross-checks for likely cost and schedule drivers.
− Develop a cost estimating checklist
111. November 8, 2022 111
Cost Estimating Process
• Step 5: Identify Ground Rules and Assumptions
− Clearly define what is included and excluded from the estimate
− Identify global and program specific assumptions such as:
• The estimate’s timescale, including time-phasing and life cycle
• Program schedule information by phase
• Program acquisition strategy
• Any schedule or budget constraints
• Inflation assumptions
• Costs such as travel and other expenses
• Equipment the organisation is to furnish
• Prime contractor and major subcontractors
• Use of existing facilities or new modifications or developments
• Technology refresh cycles
• Technology assumptions and new technology to be developed
• Commonality with legacy systems and assumed heritage savings
• Effects of new ways of doing business
• Step 6: Obtain Data
− Create a data collection plan with emphasis on collecting current and relevant technical, programmatic, cost, and
risk data.
− Investigate possible data sources
− Collect data and normalise them for cost accounting, inflation, learning, and quantity adjustments
− Analyse the data to look for cost drivers, trends, and outliers compare results against rules of thumb and standard
factors derived from historical data
− Interview data sources and document all relevant information including an assessment of data reliability and
accuracy
112. November 8, 2022 112
Cost Estimating Process
• Step 7: Develop Point Estimate
− Develop the cost model by estimating each WBS element, using the best methodology
from the data collected
− Include all estimating assumptions in the cost model
− Express costs in constant year currency
− Time-phase the results by spreading costs in the years they are expected to occur, based
on the pro gram schedule
− Sum the WBS elements to develop the overall point estimate
− Validate the estimate by looking for errors like double counting and omitting costs
− Compare estimate against the independent cost estimate and examine w here and why
there are differences
− Perform cross-checks on cost drivers to see if results are similar
− Update the model as more data become available or as changes occur and compare
results against previous estimates
• Step 8: Conduct Sensitivity Analysis
− Test the sensitivity of cost elements to changes in estimating input values and key
assumptions
− Identify effects of changing the program schedule or quantities on the overall estimate
− Determine which assumptions are key cost drivers and which cost elements are affected
most by changes
113. November 8, 2022 113
Cost Estimating Process
• Step 9: Conduct Risk and Uncertainty Analysis
− Determine the level of cost, schedule, and technical risk associated with each WBS element and discuss with
technical experts
− Analyse each risk for its severity and probability of occurrence
− Develop minimum, most likely, and maximum ranges for each element of risk
− Use an acceptable statistical analysis methodology to develop a confidence interval around the point estimate
− Determine type of risk distributions and reason for their use
− Identify the confidence level of the point estimate
− Identify the amount of contingency funding and add this to the point estimate to determine the risk-adjusted cost
estimate
− Recommend that the project office develop a risk management plan to track and mitigate risks
• Step 10: Document the Estimate
− Document all steps used to develop the estimate so that it can be recreated quickly by a cost analyst unfamiliar
with the program and produce the same result
− Document the purpose of the estimate, the team that prepared it, and who approved the estimate and on what
date
− Describe the program, including the schedule and technical baseline used to create the estimate
− Present the time-phased life-cycle cost of the program
− Discuss all ground rules and assumptions
− Include auditable and traceable data sources for each cost element
− Document for all data sources how the data were normalised
− Describe the results of the risk, uncertainty, and sensitivity analyses and whether any contingency funds were
identified
− Document how the estimate compares to the funding profile
− Track how this estimate compares to previous estimates, if applicable
114. November 8, 2022 114
Cost Estimating Process
• Step 11: Present Estimate for Approval
− Develop a briefing that presents the documented life-cycle cost estimate for management
approval, including
• An explanation of the technical and programmatic baseline and any uncertainties;
• A comparison to an independent cost estimate (ICE) with explanations of any differences;
• A comparison of the estimate (life-cycle cost estimate (LCCE) or independent cost estimate to the budget;
and
• Enough detail so the presenter can easily defend the estimate by showing how it is accurate, complete, and
high in quality.
− Focus the briefing, in a logical manner, on the largest cost elements and drivers of cost
− Make the content concise and complete so that those who are unfamiliar with it can easily
comprehend the competence that underlies the estimate results
− Make backup slides available for more probing questions
− Act on and document feedback from management
− The cost estimating team should request acceptance of the estimate
• Step 12: Update Estimate to Reflect Actual Costs and Changes
− Update the estimate to
• Reflect any changes in technical or program assumptions
• Keep it current as the program passes through new phases
− Replace estimates with EVM EAC and Independent estimate at completion (EAC) from EVM
− Report progress on meeting cost and schedule estimates
− Perform a post mortem and document lessons learned for elements whose actual costs or
schedules differ from the estimate.
− Document all changes to the program and how they affect the cost estimate
115. November 8, 2022 115
Work Breakdown Structure (WBS)
• Cornerstone of every solution delivery because it defines in detail
the work necessary to accomplish a solution’s objectives
− Essential part of developing a project’s cost estimate
− WBS reflects the delivery of the agreed requirements to the agreed solution
design
• A typical WBS reflects the requirements, resources and tasks that
must be accomplished to develop a program
• WBS communicates to everyone what needs to be done and how the
activities relate to one another
• Provides a consistent framework for planning and assigning
responsibility for the work
• Define a project in terms of product-oriented elements, broken into
a hierarchical structure
• Product-oriented WBS ensures that all costs are captured
• The WBS is derived from and expands on the previously described
solution component breakdown structure
116. November 8, 2022 116
Validating Cost Estimates
• Cost estimates should be validated against best practice
characteristics
− Comprehensive
− Well-documented
− Accurate
− Credible
117. November 8, 2022 117
Validating Cost Estimates
• Comprehensive
− Completely define the program and reflect the current schedule
− Include all possible costs using a logical WBS that accounts for all requirements
− Ensure that no costs are omitted nor double-counted
− Explain and document key assumptions that are technically reasonable
• Well-documented
− They can be easily repeated or updated and traced to original sources through
auditing
− Supporting documentation identifies the data sources, justifies all assumptions,
and provides a description of each estimating methodology for every WBS cost
element
− Schedule milestones and deliverables are traceable and consistent with the
cost estimate documentation
118. November 8, 2022 118
Validating Cost Estimates
• Accurate
− They are not overly conservative or too optimistic
− Based on an assessment of most likely costs and adjusted properly for inflation
− Contain few, if any, mistakes that are minor in nature
− Are updated when assumptions or requirements change to reflect current status
− Cost estimating relationships and parametric cost models are validated to ensure they are good predictors
of costs
• Data is current and applicable to the new program,
• The relationships between technical parameters are logical and statistically significant
• Results are tested with independent data
• Credible
− They clearly identify any limitations because of uncertainty or biases surrounding the data or assumptions
− Results are similar to cross-checks and an independent cost estimate derived using different
methodologies
• Independent cost estimates performed by estimators farthest away from the acquiring program office represent a
best practices because they
− Tend to produce higher and more accurate cost estimates than those performed by staff sharing a common supervisor
with the program office
− Produce more credible estimates than other types of independent estimate reviews which may not be as inclusive as an
ICE (e.g., IGCE, ICA, Sufficiency Review, etc.)
− A sensitivity analysis has been performed to identify cost drivers and the impacts of varying assumptions
− A risk / uncertainty analysis has been performed to determine the level of risk associated with the point
estimate
119. November 8, 2022 119
Cost Assessment Team
• Cost estimates are frequently developed with an
incomplete knowledge of what the exact final technical
solution will be
• Cost assessment team must manage a great deal of risk,
especially for programs that are complex or use leading
edge of technology
• Cost estimates define what a given solution will ultimately
cost
• Estimate will be affected by multiple assumptions and an
interpretation of what the historical data represent
120. November 8, 2022 120
Disciplines and Concepts in Cost Analysis
Economics
•Break-even Analysis
•Personnel Cost
•Inflation
•Present Value
Analysis
Cost
Analysis
Team Skills
Budgeting
•Organisation
Specific Skills
•Program Specific
Skills
Information
Technology
•Analysis
•Design
•Development
•Testing
•Scheduling
•System Integration
Statistics
•Forecasting
•Risk/Uncertainty
Analysis
Accounting
•Cost Data Analysis
•Financial Analysis
•Overhead Analysis
•Proposal Analysis
Interpersonal Skills
•Approach
•Estimate
•Knowledge
Commercial
•Analysis of
Commercial Models
•Analysis of
Proposals
•Development of
Cost Estimating
Relationship
121. November 8, 2022 121
Cost Assessment Team Best Practices Checklist
• The composition of the estimating team includes the skills
needed for the program of work
− The team has the proper number and mix of resources
− The team has the proper number and mix of resources
− The team includes experienced and trained cost analysts
− The team includes, or has direct access to, analysts experienced in
the IT portfolio’s major areas
− Team members’ experience, qualifications, certifications, and
training are identified
• A master schedule with a written study plan has been
developed
• The team has access to the necessary subject matter
experts
122. November 8, 2022 122
IT Investment Management Maturity Stages
Description
Creating Investment
Awareness
Building the Investment
Foundation
Developing a Complete
Investment Portfolio
Improving the
Investment Process
Leveraging IT for
Strategic Outcomes
5
4
3
2
1
The organisation has mastered the selection, control, and evaluation
processes and now seeks to shape its strategic outcomes by benchmarking
its IT investment processes relative to other "best-in-class" organizations.
The organisation is focused on evaluation techniques to improve its IT
investment processes and portfolio(s), while maintaining mature selection
and control techniques.
The organisation has developed a well-defined IT investment portfolio
using an investment process that has sound selection criteria and
maintains mature, evolving, and integrated selection, control, and
evaluation processes.
Basic selection capabilities are being driven by the development of project
selection criteria, including benefit and risk criteria, and an awareness of
organizational priorities when identifying projects for funding. Executive
oversight is applied on a project-by-project basis.
Ad hoc, unstructured, and unpredictable investment processes
characterise this stage. There is generally little relationship between the
success or failure of one project and the success or failure of another
project.
123. November 8, 2022 123
Increasing IT Investment Management Maturity
1 Creating Investment
Awareness
2 Building the Investment
Foundation
3 Developing a Complete
Investment Portfolio
4 Improving the
Investment Process
5 Leveraging IT for
Strategic Outcomes
1. The organisation learns from and adopts the tools,
techniques, or methods used by best-in-class external
organisations
2. Changes to strategic business processes are driven by the
capabilities of identified information technologies
1. Evaluation techniques are being used to improve the
investment processes and the portfolio
2. Succession management processes are developed for
retaining or disposing of investments.
1. Criteria are developed for identifying investments that best
fit with the portfolio.
2. The portfolio is developed through the use of categorisation
when comparing investments.
3. Performance reviews are conducted both during and after
implementation
1. An investment board is established to drive the investment
process
2. Business needs are identified for each project
3. An investment selection process is developed
4. Board oversees the progress of individual projects
5. Investment information is collected and disseminated
124. November 8, 2022 124
IT Investment Management
• Aligns IT Investments to organisation strategy (scoring)
• Prioritises investments (ranking)
• Provides strategic criteria for investment analysis
• Conduct annual IT portfolio management reviews
• Provides recommendation to stop, slow, maintain or
accelerate program funding
• Identifies redundant/inefficient systems
• Integrates IT architectures within investments
• Ensures compliance with funding standards
125. November 8, 2022 125
Characteristics of Credible Cost Estimates
• Clear identification of requirements of the ultimate deliverable
• Broad participation in preparing estimates
• Availability of valid data for performing estimates – historical,
experience, benchmarks
• Standardised and comprehensive estimate structure that includes all
possible sources of cost
• Provision for uncertainties – include known costs explicitly and allow
for unknown costs
• Recognition of inflation
• Recognition of excluded costs
• Independent review of estimates for completeness and realism
• Revision of estimates for significant changes in requirements
126. November 8, 2022 126
Challenges of Developing Good Cost Estimates
• Requires detailed, stable, agreed requirements
• Agreed assumptions
• Access to detailed documentation and historical data for
comparison
• Trained and experienced analysts
• Risk and uncertainty analysis
• Identification of a range of confidence levels
• Adequate contingency and management reserves
127. November 8, 2022 127
Sources of Risk and Uncertainty in Estimating Costs
• Lack of understanding of the project requirements
• Shortcomings of human language and differing
interpretations of meaning of project
• Behaviour of parties involved in the cost estimation
process
• Haste
• Deception
• Poor cost estimating and pricing practices