Transcript Sanyal Technology Solutions

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 Approach
End-to-End Approach





Enterprise Transformation Planning
Initiative & Architecture Roadmapping
Solution Analysis and Design
Program/Project Management Support
Implementation Support
3
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
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
Key Enterprise Architecture Consideration
Characterize the type of enterprise to understand
opportunities for standardization and integration of business
processes and underlying IT capabilities.
Four Types
 Unification
 Replication
 Coordination
 Diversification
Business Process
Standardization
Business Process
Integration
5
Target Operating Model Type Assessment
Description
Diversification
Coordination
Replication
Unification
Independent
business units with
shared services
(eg: HR,
procurement, etc.)
Seamless access to
shared data,
integration among
processes for
improved customer
support, crossselling, 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
Ensure IT KPI’s support and enable Business KPI’s.
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
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 Analysis
 Target End State Blueprint
 Business Prioritization
 Assess Dependencies
 Assess Delivery Capacity
 Incremental Roadmap
 Challenges Realizing Target State
9
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.
10
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-ofthe-box lift.
 Complexity of business processes are underestimated,
resulting in significant cost / schedule underestimation, or
business case annulment.
11
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 CrossImpacting 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 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 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 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 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-tomarket based on business priorities. Ensure transparency
around projected rework and obtain business & IT
stakeholder buy-in.
15
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 approach.

Ensure risks and shortcomings of tactical approach are communicated to
prioritize mitigation.
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 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.
18
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 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
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 architect’s “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
20
Solution Analysis Inputs
Other 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 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 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.
22
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, 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 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-thebox 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 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.
25
Architectural Views
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)






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.
26
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
isolation.
27
Performance
Depending 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 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 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 Architecture
At 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 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 as:

Unproven capabilities that are assumed to exist about a technology
component

Solution components that are delivered by another initiative
31
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
32
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 Issues
Review and signoff on major project and design documentation
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.
33
Thank You for the
Opportunity!
34