Sanyal Technology Solutions - PowerPoint PPT Presentation

1 / 34
About This Presentation

Sanyal Technology Solutions


Sanyal Technology Solutions Architecture Consulting Approach (an Overview) By Steve Sanyal, a Pragmatic Architect Version: September 16, 2014 – PowerPoint PPT presentation

Number of Views:119
Avg rating:3.0/5.0
Slides: 35
Provided by: SteveS234


Transcript and Presenter's Notes

Title: Sanyal Technology Solutions

Sanyal Technology Solutions
  • Architecture Consulting Approach
  • (an Overview)
  • By Steve Sanyal, a Pragmatic Architect
  • Version September 16, 2014

Executive Summary
  • Purpose Describe a holistic approach and
    learnings that can be systematically applied
    across organizations for providing architecture
    consulting to IT-driven transformational
  • Key Influences
  • Zachman
  • Enterprise Architecture as Strategy
  • Project Management Body of Knowledge
  • Relevant Experience

Architecture Consulting Approach
  • End-to-End Approach
  • Enterprise Transformation Planning
  • Initiative Architecture Roadmapping
  • Solution Analysis and Design
  • Program/Project Management Support
  • Implementation Support

Enterprise Transformation Planning
  • Purpose 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
  • Analysis Approaches
  • Target Operating Model Type
  • Enterprise Architecture Core Diagram
  • Value Chain
  • Capability Maturity Model
  • Business Case
  • Risk Assessment

Target Operating Model Type
Key Enterprise Architecture Consideration
Characterize the type of enterprise to understand
opportunities for standardization and integration
of business processes and underlying IT
  • Four Types
  • Unification
  • Replication
  • Coordination
  • Diversification

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 Target Operating Model Business Process Characteristics Target Operating Model Business Process Characteristics Target Operating Model Business Process Characteristics Target Operating Model Business Process Characteristics
Degree of Standardization ? - Low ? - Low ? - High ? - High
Degree of Integration ? - Low ? - High ? - Low ? - High
Enterprise Characteristics Enterprise Characteristics Enterprise Characteristics Enterprise Characteristics 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 Characteristics IT Characteristics IT Characteristics 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
Value Chain Analysis
Ensure IT KPIs support and enable Business KPIs.
  • 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.

Simplified illustrative example for fraud
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.

Initiative Architecture Roadmapping
  • So now that we know our transformational scope,
    how do we achieve it? Big Bang or
  • Analysis Approach
  • Current State Analysis
  • Target End State Blueprint
  • Business Prioritization
  • Assess Dependencies
  • Assess Delivery Capacity
  • Incremental Roadmap
  • Challenges Realizing Target State

The Value of Current State Analysis
  • Initiatives 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.

The Value of Current State Analysis
  • Common 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
  • Complexity of business processes are
    underestimated, resulting in significant cost /
    schedule underestimation, or business case

Target End State Blueprint
  • What 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.

Initiative Interdependency
  • How do we sequence initiatives within the
    transformational opportunity to arrive at target
    end state? Support business and PMO in
    evaluating the architectural dependencies between
  • 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?

Delivery Planning
  • Provide 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
  • What cross-impacts from other initiatives may
    affect our delivery plan (ie increase risk)?
  • What is our delivery capacity (resources,
  • 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
  • What is the risk profile of meeting our delivery

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.

When Plans Go Bump In the Night
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?
  • 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
  • Ensure risks and shortcomings of tactical
    approach are communicated to prioritize

Solution Analysis and Design
  • 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 Reqs, Business Scenarios, Business
    Process Maps, Use Cases, User Stories, and
    Functional Specifications
  • Ambiguous 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.

Enterprise Architecture Maturity
  • Understand 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 management
  • Optimized Core companywide data and process
  • Business Modularity Manage, reuse loosely
    coupled IT-enabled business process components to
    preserve global standards, enable local
    differences where needed.

Enterprise Architecture Maturity
Learning requirements of the architecture stages
incorporated as input into Solution design
process, because it will significantly influence
what kind of outcomes are possible. For
example Business Modularity may be every
architects dream, but if an organization is at
Stage 1 or 2, it will be very difficult to
overcome ownership challenges.
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
Solution Analysis Inputs
  • Other essential inputs for Solution Analysis
  • 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
  • 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.)

Architecture Principles
  • Architecture 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
  • IT standards will be leveraged for solution
  • Data will be accessed directly from the book of
    record instead of replicated.
  • Additional Reference IBM architecture principles
    for financial sector.

Identify and Evaluate Solution Options
  • Systematically 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, SMEs 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.

Identify and Evaluate Solution Options
  • Summarized 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
    applications 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.

Request for Proposal
  • Influence decision-making on whether an RFP
    proposal may be required. Provide leadership to
    the following activities
  • Identify and short-list vendors
  • Identify 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.

Architectural Views
Provide representations of the end-to-end
solution across all architecture domains to
support understanding across stakeholders
(business, IT management, SMEs, vendors). These
views are the ones typically employed, however,
views can be customized as needed. (from TOGAF 8
  • 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
  • Physical View Depict runtime processing nodes
    including hardware, software and network
    infrastructure to support configuration of the
    environment for meeting the non-functional
  • 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
  • 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.

Sizing and Capacity
  • Assess 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

  • Depending on an organizations 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
  • 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
  • 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
  • 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.

Business Continuity and QoS
  • Define 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 RPOs (ie in hours
    or days) may use less costly off-site data backup
  • High Availability The ability for the system to
    sustain component failures without suffering
    degradation in the QoS. Solutions employ
    component redundancy (n1 or nm, 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 (9s).
  • 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?

Operations Architecture
  • At the end of the day, someone must support and
    maintain your solution. Here are things to think
  • 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
  • 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?

Technology Risks and Assumptions
  • Identify and mitigate technology risks for an
    initiative, such as
  • Use of new, unproven technologies
  • Lack of IT skills for implementing the solution
  • Use of vendor resources (may increase or lower
    risk depending on the vendor)
  • Requirements that are too broad or unclear
  • Risk presented by solution complexity
  • Outline all assumptions being made about the
    solution, which will add risk if incorrect, such
  • Unproven capabilities that are assumed to exist
    about a technology component
  • Solution components that are delivered by another

Stakeholder Review Acceptance
  • Decisions 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 stakeholders
  • Formal presentations for review by business and
    IT stakeholders and an Architecture Review Board
    as required
  • Capture 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

Project Management Implementation Support
  • Support various activities, such as
  • Help define the work breakdown structure and
    delivery approach for the initiative
  • Deconstruct and provide options analysis for
    contentious issues as they arise
  • Manage relationships with vendors and ensure
    quotations contain the required information
  • Identify and facilitate communications with
    Project Stakeholders and Executives by providing
    effective summaries of technical and Project
  • Review and signoff on major project and design
  • Proactively promote business technology
    alignment, understanding across all stacks
    pertinent to the solution
  • Work within varied project management methodology
    approaches such as gated waterfall and agile
  • Provide leadership to technical teams and drive
    complex activities such as performance testing to
    support IT teams where required
  • Provide trouble-shooting expertise across
    technology stacks as problems arise during
    implementation to ensure success
  • Provide special consideration inputs to QA leads
    to ensure boundary cases are handled.

Thank You for the Opportunity!
Write a Comment
User Comments (0)