Sanyal Technology Solutions

Architecture Consulting Approach

(an Overview)

By Steve Sanyal, a “Pragmatic Architect”

Version: September 16, 2014

1

Executive Summary

Purpose: Describe a holistic approach and learnings that can be systematically applied across organizations for providing architecture consulting to IT-driven transformational initiatives.

Key Influences:•TOGAF•Zachman•Enterprise Architecture as Strategy•Project Management Body of Knowledge•Relevant Experience

2

Architecture Consulting ApproachEnd-to-End Approach

Enterprise Transformation PlanningInitiative & Architecture Roadmapping Solution Analysis and DesignProgram/Project Management SupportImplementation Support

3

Enterprise Transformation PlanningPurpose: Apply a systematic approach to business transformation

planning. Define the scope of the enterprise, define business strategy with a set of transformational objectives and supporting rationale.

Analysis Approaches Target Operating Model Type Enterprise Architecture Core Diagram Value Chain Capability Maturity Model Business Case Risk Assessment

4

Target Operating Model Type

Four Types Unification Replication Coordination Diversification

Characterize the type of enterprise to understand opportunities for standardization and integration of business processes and underlying IT capabilities.

Business ProcessIntegration

Business ProcessStandardization

Key Enterprise Architecture Consideration

5

Target Operating Model Type Assessment  Diversification Coordination Replication Unification

Description

Independent business units with shared services (eg: HR, procurement, etc.)

Seamless access to shared data, integration among processes for improved customer support, cross-selling, supply-chain transparency.

Standardized Independence to support efficient, repeatable business processes rather than shared relationships.

Standardized, Integrated Processes to support integrated supply chains and interdependence across distributed business units.

Target Operating Model Business Process Characteristics

Degree of Standardization ○ - Low ○ - Low ● - High ● - High

Degree of Integration ○ - Low ● - High ○ - Low ● - High

Enterprise Characteristics

Shared customers, suppliers, products ○ - Low ● - High ○ - Low ● - High

Transactional independence across business units ● - High ○ - Low ● - High ○ - Low

Operationally similar business units ○ - Low ○ - Low ● - High ● - High

Centralized control over business process design ○ - Low ○ - Low ● - High ● - High

Shared customer/supplier/product data ○ - Low ● - High ○ - Low ● - High

Standardized data definitions ○ - Low ● - High ● - High ● - High

IT Characteristics

IT application decisions made by individual business units ● - High ● - High ○ - Low ○ - Low

Consistent processes for designing IT infrastructure services ○ - Low ● - High ● - High ● - High

6

Value Chain Analysis

Assess the value chain to determine which activities and capabilities will offer the enterprise the greatest competitive advantage on cost and product or service superiority.

Ensure IT KPI’s support and enable Business KPI’s.

Simplified illustrativeexample for fraud

7

Enterprise Transformation Assessment Approaches Enterprise Architecture Core Diagram: Define the business

processes, data and integration describing how the enterprise operates. (from Enterprise Architecture as Strategy)

Capability Maturity Modeling: Identify capabilities and define how to incrementally measure its maturity through review of industry information and organization objectives. Assess current maturity and target maturity based on business priorities (1y, 3y, 5y plans).

Business Case Analysis: Evaluate competing objectives within the transformation by understanding the required initial investment, the risk/reward profile including the ROI, and other cost/benefit characteristics (eg: preventing reputational loss).

Risk Assessment: To prioritize risk mitigation objectives, understand the residual risk profile by assessing risk based on degree of harm, compensating factors and controls.

8

Initiative & Architecture Roadmapping So now that we know our transformational scope, how do we achieve it? Big Bang or Incremental/Phased?

Analysis Approach:Current State AnalysisTarget End State BlueprintBusiness PrioritizationAssess DependenciesAssess Delivery CapacityIncremental RoadmapChallenges Realizing Target State

9

The Value of Current State AnalysisInitiatives may underestimate the importance

of current state in transformational initiatives where capabilities are being replaced. This often compromises understanding the size, cost, complexity of the initiative.

Current state analysis provides invaluable insight into the requirements of the target end state and helps mitigate risk by preventing weak assumptions and missed requirements such as important exception and alternative path scenarios which add significant scope.

10

The Value of Current State AnalysisCommon transformation problems due to lack of current state analysis.A vendor product is selected as a replacement solution, but the high cost and time-to-market of customizations required to replace important current state capabilities outweigh the value of purchasing the product for its out-of-the-box lift.Complexity of business processes are underestimated, resulting in significant cost / schedule underestimation, or business case annulment.

11

Target End State BlueprintWhat is the target architecture?

Work Breakdown: Decompose initiative into multiple workstreams, if required to parallelize analysis effort.Architecture Inputs: Current State, High Level and Detailed Requirements, Business Process Maps, Non Functional Requirements, Known Cross-Impacting Initiatives, Funding Approach.Architecture Outputs: Solution Analysis and Design of Target End State, Facilitate Cost Estimation by IT Teams and Vendors, Identify Risks and Assumptions, Stakeholder Review, Mapping of Conceptual Architecture (Technology TOM) to Target Operating Model.

12

Initiative InterdependencyHow do we sequence initiatives within the transformational opportunity to arrive at target end state? Support business and PMO in evaluating the architectural dependencies between capabilities.

What are “low hanging fruit” we can deliver quickly and provide business value?What initiatives have the highest time-to-market priority (eg: to protect customer base, address regulatory requirement, etc.)?Do we require “Foundational” initiatives to lay groundwork? Ie. Doing X now is required to achieve A,B,C.Can we maximize overall ROI by delivering some initiatives sooner than others? Ie. If we do X now, we will earn more $ over 3 years than if we do Y now.Can we minimize technology rework by doing X before we do Y?

13

Delivery PlanningProvide architecture input and guidance into Business, PMO and delivery team planning:How much funding can we devote to the initiative per fiscal year until we achieve target end state?What cross-impacts from other initiatives may affect our delivery plan (ie: increase risk)?What is our delivery capacity (resources, environments)?How quickly will the target blueprint become stale (eg: due to evolving technologies and/or changes in business need?)Is there a business case and potential to augment our capacity (resources, environments) to reduce schedule?What is the risk profile of meeting our delivery targets?

14

Incremental Roadmap Define the roadmap for achieving target end state, ie:

target operating model capabilities achieved and corresponding architecture.

Use incremental “transition states” to depict how the architecture evolves with each project within the overall transformation.

Deliver sufficient value in each transition state to support business case.

Assess tactical options as necessary to reduce time-to-market based on business priorities. Ensure transparency around projected rework and obtain business & IT stakeholder buy-in.

15

When Plans Go Bump In the Night

Examples:An “end-of-life” technology compromises current state reliability and business priorities require a targeted objective “time-to-market” solution.Market pressures require an accelerated “time-to-market” solution.

Approach:Employ tactical time-to-market solutions that minimize schedule and future rework effort.Ensure business acknowledges and accepts rework implications required by employing a tactical approach.Ensure risks and shortcomings of tactical approach are communicated to prioritize mitigation.

“When we least expect it, life sets us a challenge to test our courage and willingness to change” – Paulo Coelhlo

How do we deal with accelerated “time-to-market” needs that challenge our roadmap for achieving strategic target state?

16

Solution Analysis and Design

17

Requirements

Provide architecture input (Development cost, Complexity, TTM, TCO, Risk considerations) and leadership for drafting requirements:

Known Requirements: refine solution as formal requirements become known High Level Req’s, Business Scenarios, Business Process Maps, Use Cases, User

Stories, and Functional SpecificationsAmbiguous Requirements: where requirements are not known, consult stakeholders to make assumptions about requirements to support solution design and cost estimation. Ensure the project identifies the gap, and the solution is revised when formal requirements are established.“Out-of-Scope” Candidate Requirements: It is important for an architect to identify & challenge requirements that do not add value, or may not have a supporting business case (eg: high complexity analysis and high cost of implementation for a “nice to have” feature). For the dialogue to be productive, deconstructing the cost/benefit characteristics of the requirement providing alternatives with pros and cons is a useful technique.

18

Enterprise Architecture MaturityUnderstand the current state of enterprise architecture maturity, and desired target end state as input into Architecture Principles and Solution Analysis approach.

Business Silos – maximize individual business unit needs or functional needs.Standardized Technology – provide IT efficiencies through technology standardization and centralization of technology managementOptimized Core – companywide data and process standardization Business Modularity – Manage, reuse loosely coupled IT-enabled business process components to preserve global standards, enable local differences where needed.

19

Enterprise Architecture Maturity

Business Silos Standardized Technology

Optimized Core Business Modularity

IT capability Local IT applications Shared technical platforms

Companywide standardized processes or data

Plug-and-play business process modules

Business objectives ROI of local business objectives

Reduced IT costs Cost and quality of business operations

Speed to market; strategic agility

Funding priorities Individual applications

Shared infrastructure services

Enterprise applications

Reusable business process components

Key management capability

Technology enabled change management

Design and update of standards; funding shared services

Core enterprise process definition and measurement

Management of reusable business processes

Who defines applications

Local business leaders

IT and business unit leaders

Senior management and process leaders

IT, business and industry leaders

Key IT governance issues

Measuring and communicating value

Establishing local/regional/global responsibilities

Aligning project priorities with architecture objectives

Defining, sourcing and funding business modules

Strategic implications Local/functional optimization

IT efficiency Business operational efficiency

Strategic agility

Learning requirements of the architecture stages – incorporated as input intoSolution design process, because it will significantly influence what kind of outcomes are possible. For example: Business Modularity may be every architect’s “dream”, but if an organization is at Stage 1 or 2, it will be very difficult to overcome ownership challenges.

20

Solution Analysis InputsOther essential inputs for Solution Analysis include:

Industry Research: Review industry research (Gartner, Forrester, etc.) to understand how the problem is being tackled in the industry. Review “Magic Quadrant” analysis to assess which vendor solutions may be a fit for the requirements.Reference Architectures & Implementations: Review existing patterns for solving the problem within the organization or across the industry. Consult IT team SMEs and vendors to investigate. Establish what has already been implemented by the IT organization or others to support risk identification.IT Standards & Strategies: Incorporate known IT standards and strategies into solution design process (eg: application server and OS standards, server virtualization strategy, cloud strategy, ESB strategy, threat mitigation strategy, etc.)

21

Architecture PrinciplesArchitecture principles form a set of general rules and guidelines for the architecture being developed. They are intended to be enduring, and simplify the decision making process during options analysis (from TOGAF).

Simplified Examples:Reusable solutions will be favored to support TCO savings.IT standards will be leveraged for solution design.Data will be accessed directly from the book of record instead of replicated.Additional Reference: IBM architecture principles for financial sector.

Architecture Principles for Financial Sec

22

Identify and Evaluate Solution OptionsSystematically assess options and make a recommendation using a critical thinking framework which is reviewed and accepted by all required stakeholders.Motivation / Problem Statement – what is the problem being solved and why?Current State –how is the problem addressed in current state?Assumptions and Inferences – what facts are we going to assume (based on supporting rationale) and what characteristics of the solution can be inferred based on available information?Options/Alternatives – what are the options identified by the architect upon investigation with stakeholders, SME’s and available knowledge? What are the pros, cons, risks and implications of each option?Decision Factors – Systematic deconstruction of pros/cons and risks, eg: fit for requirements, cost, complexity, performance, scalability, safety and soundness, maintainability, resource availability, etc.Recommendation: After evaluating the decision factors, what is the recommended approach and rationale? What are the fallbacks?Implications and Risks: As a result of the recommendation, what further actions must the initiative or the organization take, and what are the risks that must be accepted?Proof of Concept: As required, perform a proof of concept to test out new patterns and technologies to mitigate risk.

23

Identify and Evaluate Solution OptionsSummarized examples of real solution options that have been evaluated:

Whether to localize a piece of specialized security functionality within an application, or externalize it in a reusable module at higher cost to which context must be passed back and forth. The value of reuse and handle change becomes the determining factor.Where to place data filtering logic – downstream within an ETL tool or upstream within scripts. Key considerations are performance based on data volume, value of retaining information further downstream, filtering capabilities of ETL tool.Whether to use a software cryptography library or leverage a hardware security module for transaction signing functions. Key considerations are supported platforms for any HSM components that run locally on the application server, secure/centralized key management for either approach, performance, security zone of the application in relationship to the security zone of the HSM being considered.Whether to run a component on a shared infrastructure (where available) or a separate standalone environment. The SLA, TTM lift, shared capabilities/resources versus limitations, QoS, TCO are key considerations.Whether to run an application active/active across two data centres, or active/passive. Key considerations are implementation cost, recovery time, complexity and platform specific idle capacity minimization approach.What platform to use for event processing – i) J2EE custom SOA, ii) Websphere Message Broker, iii) Data Power. The key considerations are licensing cost of product, need for parallelism, ability for the implementation to scale and perform, time to market for delivery and manage changes, integration capabilities of the platform, out-of-the-box lift the platform provides, ability to support desired MOM integration approach (in this case pub/sub).Where to get data to meet the needs of an application’s operational, client facing reporting capabilities – i) from operation systems, ii) from a centralized data warehouse? The key considerations are what are appropriate authoritative sources of information, and the latency characteristics of the sources versus the required SLA.

24

Request for ProposalInfluence decision-making on whether an RFP proposal may be required. Provide leadership to the following activities:Identify and short-list vendorsIdentify IT questions to be asked to vendors and coordinate IT response scoring.Support business in understanding the amount of out-of-box functionality a product provides, versus what must be added through customization.Work with procurement & vendor to understand the licensing model to assess IT cost.Assess the out-of-box integration capabilities for the product.Assess professional services needs.Work with vendor to size the product.Facilitate a consensus recommendation from IT on which product should be selected.

25

Architectural Views

Conceptual View: An end-to-end view of the solution usually created at the early stages of a large scale initiative to provide context about the solution scope. Candidate technologies may be identified, and options highlighted to support decision making.

Use case realization views: System sequence diagrams which depict the end-to-end integration required across a distributed solution to satisfy a use case scenario.

Logical View: Depict application components, application flow and integration of all components in the solution, including the choice of technology for each component. Also depict any horizontal capabilities such as system monitoring.

Physical View: Depict runtime processing nodes including hardware, software and network infrastructure to support configuration of the environment for meeting the non-functional requirements.

Security View: Typically an overlay of the logical view which describes the security characteristics of the end-to-end solution, including security zones, trust, authentication and authorization mechanisms and audit capabilities.

Data View: Describe the entities and their relationships, to support design of underlying database components.

*View notation is tailored based on the organization and the audience.

Provide representations of the end-to-end solution across all architecture domains to support understanding across stakeholders (business, IT management, SME’s, vendors). These views are the ones typically employed, however, views can be customized as needed. (from TOGAF 8 & Zachman)

26

Sizing and CapacityAssess the needs of the end-to-end environment based on non-functional requirements and behavioural characteristics, such as:

Workload model: Understand the workload mix and load implications based on known/estimated behaviour patterns. Use existing workload data if available, analyze raw data, or perform thought experiments to assess. Establish average and peak workloads including throughput spikes to support sizing, and use simulations for sizing benchmarks if required. Operations teams may also use the workload model to initially determine component placement within a server farm with shared resources.Environment Sizing & Scalability: Determine the size of the environment required to support the peak workload, performance requirements and expected growth profile. Provide enough whitespace (often ~40% of total capacity depending on volatility) for spikes and normal growth. Sizing will also result in establishing the hardware and software licensing cost, ongoing maintenance, and operational costs for running the infrastructure.Storage Capacity: Assess the amount of data that will accumulate in the system to support the storage sizing and archiving needs, as required. This may incorporate information such as database table size, file sizes, etc.Idle Capacity: Minimize idle capacity to help support total cost of ownership benefit. The approach employed will depend on platform. Some platforms (eg: AIX) may have special provisions to spin-up a production disaster recovery environment with a corresponding spin-down of a test environment on the same server using virtual IO servers to provide required security zone isolation.

27

PerformanceDepending on an organization’s performance testing maturity, an architect may have a strong role to play in ensuring performance requirements and testing is adequately addressed:

SLA considerations: Typically response times are expressed in percentile (eg: 99% of requests will return within 5 seconds). However, SLA should be tailored based on end-to-end consideration of the solution – if key backend components do not support the response time SLA, this must be stated as a limitation and addressed if necessary.Performance Environment: The performance environment should be configured identical to production for accurate results. In addition, assuming linear scalability the size of the performance environment relative to production must be factored into planning the performance workload.Test Case Selection: Candidates for performance are scenarios which occur in high velocity, high volume, and/or have a high resource consumption on the system under design. Ensure these are identified and included. An overall workload simulation test may also be performed, depending on schedule impact and risk.Monitoring: Ensure monitoring is configured for the test environment so resource consumption and network throughput can be measured throughout the test. Employ a profiling tool (eg: Dynatrace) to support troubleshooting and identifying candidate optimizations.Testing Approaches -- Load testing simulates production and measure response times. Endurance testing simulates production load for a long duration to ensure stability (eg: identify memory leaks). Stress tests establish the scalability and failure point of the current environment, identify non-linear scalability bottlenecks and provide input into growth planning.

28

Business Continuity and QoSDefine how the end-to-end solution will satisfy quality of service (QoS) and support business continuity planning. It is important to assess business impact of various approaches, and the constraints of the IT organization. The following topics should be covered:Recovery Time Objective – how long after a disaster or disruption must service be restored? The highest RTO of a key component dictate the constraints of the solution. For example, a distributed UNIX application may have an RTO of minutes, however, if its core functionality requires integration with a mainframe that has an RTO in hours, the solution is constrained to the mainframe RTO.Recovery Point Objective – The maximum amount of time data might be lost. An RPO of zero requires synchronous storage replication to a disaster recovery site. Low-latency asynchronous replication support near-zero RPO and improve performance. Higher non-zero RPO’s (ie: in hours or days) may use less costly off-site data backup approaches.High Availability – The ability for the system to sustain component failures without suffering degradation in the QoS. Solutions employ component redundancy (n+1 or n+m, where n = full load) and/or active/active topologies. The underlying resiliency of the platform (eg: premium versus commoditized hardware) is an important consideration and requires understanding of how availability has been measured (#9’s).Fault Tolerance – How does a system behave when a component failure occurs? Are in progress transactions lost? Does the user have to re-establish a session, or is the session replicated? Cost, complexity, performance are important considerations for deciding.Disaster Recovery – How will the solution address a disaster scenario? Will the disaster site offer the same QoS as the production site? How can the cost of the disaster site servers be justified? If QoS is the same in the disaster site, can the site be used to add business value such as faster rollback recovery when a new release of an application occurs?

29

Operations ArchitectureAt the end of the day, someone must support and maintain your solution. Here are things to think about.

Service Level Agreements – Formal QoS requirements between business and IT based on capabilities, eg: data latency requirements, performance requirements, etc. An SLA may tend toward supporting business KPI measure, or highlighting a constraint in IT which is a pain point for business. The latter case may be a candidate for future transformation.

Operating Level Agreements – Defines the interdependent relationships between business and IT internal support groups, and must be considered when constructing the overall SLA.

Supportability – Do operational teams have the knowledge and experience to support the system if a problem occurs? Does the solution require justifiable special considerations above and beyond other solutions? Does the solution enable effective troubleshooting?

Manageability – How many teams are required to operate the solution and handle “bumps in the night”? As the number of teams increase, the manageability decreases exponentially because of the increased troubleshooting complexity.

Monitoring & Alerts – How can we proactively assess production activity and outages by monitoring resource consumption, using health checks, and measuring throughput.

Security and Audit -- What are security and audit controls in the underlying architecture? For example, do file system permissions adequately protect and detect unauthorized access?

Current Optimizations – This is a current state variant targeted at operational architecture. How are operations currently optimized, and what are the change implications of deviating from current state?

30

Technology Risks and AssumptionsIdentify and mitigate technology risks for an initiative, such as:Use of new, unproven technologiesLack of IT skills for implementing the solutionUse of vendor resources (may increase or lower risk depending on the vendor)Requirements that are too broad or unclearRisk presented by solution complexity

Outline all assumptions being made about the solution, which will add risk if incorrect, such as:Unproven capabilities that are assumed to exist about a technology componentSolution components that are delivered by another initiative

31

Stakeholder Review & AcceptanceDecisions about the solution, and ongoing reviews are conducted using a variety of approaches:

Use of formal decision and solution description documents, with sign-off from stakeholdersFormal presentations for review by business and IT stakeholders and an Architecture Review Board as requiredCapture meeting minutes from group discussions so decisions, risks, action items and pertinent information are retained in writing to help maintain shelf-life of understanding, and support future conflict resolution if required

32

Project Management & Implementation SupportSupport various activities, such as:

Help define the work breakdown structure and delivery approach for the initiativeDeconstruct and provide options analysis for contentious issues as they ariseManage relationships with vendors and ensure quotations contain the required informationIdentify and facilitate communications with Project Stakeholders and Executives by providing effective summaries of technical and Project IssuesReview and signoff on major project and design documentationProactively promote business & technology alignment, understanding across all stacks pertinent to the solutionWork within varied project management methodology approaches such as gated waterfall and agileProvide leadership to technical teams and drive complex activities such as performance testing to support IT teams where requiredProvide trouble-shooting expertise across technology stacks as problems arise during implementation to ensure successProvide special consideration inputs to QA leads to ensure boundary cases are handled.

33

Thank You for the Opportunity!

34