Target State Architecture TSA

advertisement
Target State Architecture
TSA
Presented by Dawn Michels
Enterprise Information Architect
Andersen Corporation
Feb 15, 2006
For Dama Minnesota
What is a TSA?


A TSA (Target State Architecture) is a tool or
method for the IT and Business functions of a
company to work in concert to insure that
business needs are addressed using the
capabilities of IT most effectively.
In addition it is written in terms that resonates
with the business and is validated and approved
by key stakeholders of both parts of the
organization.
Our approach was to…

Assess




Organize



Develop principles and values
Develop specific list of architectures
Document



Understand and assess key business strategies
and business unit plans
Evaluate current business models, high levelgaps between business process and
technology offerings
Identify IT organizational implications
Identify specific opportunities & pain points
Document current and target states of specific
architectures
Prioritize


Prioritize business needs/intersection with IT
capabilities
List specific initiatives that would move us in
the right direction
Who Participated





Executive Leadership
Business Management
Sr. IT Management
Enterprise Architects
Business/IT Liaisons
Assess




The Enterprise architecture team reviewed
business strategies and work plans after they were
crafted by the business units
Next they identified what technical capabilities
were required to support these strategies
Gathered the known supporting applications
Identified where IT organizational implications
might be experienced
Organize



A core team of Architects and Sr. Management (both
business and IT) developed a core list of principles
and value statements between both organizations
Gathered list of known supporting applications
Identified where IT organizational implications
might be experienced do to potential change
Document




Created a list of business, information, solution
and technical architectures
Documented pain points, opportunities and
current business activities
Created graphical representations where
appropriate – illustrating current state
Validated with key business liaisons



Identifying scope of effort
Resources & costs estimates
Iterative steps / roadmap to achieve Target State
Prioritize




Provided an overall synopsis to business of
requirements as well as sampling of TSA’s
Asked business to prioritize which capabilities
were most important to them, and which would
coincide best with expected work activities this
year
Applied these needs to our own resource and
staff planning
Reviewed with business and secured support
from them as well as shared resources.
A picture is worth a 1000 words


Identify a framework that you can rally
around
Examples




Business Strategy
Architecture
Vision Directed
Business/IT directed
ENTERPRISE ARCHITECTURE - A FRAMEWORK
DATA
What
FUNCTION
How
Where
PEOPLE
Who
TIME
When
Why
List of Things Important
to the Business
Planner
ENTITY = Class of
Business Thing
Function = Class of
Business Process
Node = Major Business
Location
People = Major Organizations
Time = Major Business Event
Ends/Means=Major Bus. Goal/
Critical Success Factor
e.g. Semantic Model
e.g. Business Process Model
e.g. Logistics Network
e.g. Work Flow Model
e.g. Master Schedule
e.g. Business Plan
Ent = Business Entity
Reln = Business Relationship
Proc. = Business Process
I/O = Business Resources
Node = Business Location
Link = Business Linkage
People = Organization Unit
Work = Work Product
Time = Business Event
Cycle = Business Cycle
End = Business Objective
Means = Business Strategy
e.g. Logical Data Model
e.g. "Application Architecture"
e.g. "Distributed System
Architecture"
e.g. Human Interface
Architecture
e.g. Processing Structure
Ent = Data Entity
Reln = Data Relationship
Proc .= Application Function
I/O = User Views
Node = I/S Function
(Processor, Storage, etc)
Link = Line Characteristics
People = Role
Work = Deliverable
Time = System Event
Cycle = Processing Cycle
End = Structural Assertion
Means =Action Assertion
TECHNOLOGY
MODEL
(PHYSICAL)
e.g. Physical Data Model
e.g. "System Design"
e.g. "System Architecture"
e.g. Presentation Architecture
e.g. Control Structure
e.g. Rule Design
Builder
Ent = Segment/Table/etc.
Reln = Pointer/Key/etc.
Proc.= Computer Function
I/O = Screen/Device Formats
Node = Hardware/System
Software
Link = Line Specifications
e.g. Data Definition
e.g. "Program"
e.g. "Network Architecture"
Ent = Field
Reln = Address
Proc.= Language Stmt
I/O = Control Block
Node = Addresses
Link = Protocols
e.g. DATA
e.g. FUNCTION
e.g. NETWORK
DETAILED
REPRESENTATIONS
(OUT-OFCONTEXT)
SubContractor
FUNCTIONING
ENTERPRISE
Zachman Institute for Framework Advancement - (810) 231-0531
People = User
Work = Screen Format
e.g. Security Architecture
People = Identity
Work = Job
e.g. ORGANIZATION
List of Business Goals/Strat
Time = Execute
Cycle = Component Cycle
Planner
ENTERPRISE
MODEL
(CONCEPTUAL)
Owner
e.g., Business Rule Model
SYSTEM
MODEL
(LOGICAL)
Designer
TECHNOLOGY
CONSTRAINED
MODEL
(PHYSICAL)
Builder
End = Condition
Means = Action
e.g. Timing Definition
e.g. Rule Specification
Time = Interrupt
Cycle = Machine Cycle
End = Sub-condition
Means = Step
e.g. SCHEDULE
SCOPE
(CONTEXTUAL)
Business
Business
Business
Infrastructure
Solutions
SYSTEM
MODEL
(LOGICAL)
Designer
List of Organizations
Important to the Business
Business
Information
Owner
List of Locations in which
the Business Operates
List of Events Significant
to the Business
MOTIVATION
SCOPE
(CONTEXTUAL)
ENTERPRISE
MODEL
(CONCEPTUAL)
List of Processes the
Business Performs
NETWORK
TM
e.g. STRATEGY
DETAILED
REPRESENTATIONS
(OUT-OF
CONTEXT)
SubContractor
FUNCTIONING
ENTERPRISE
Copyright - John A. Zachman, Zachman International
(used with permission)
An Architecture Framework
Principle or Value
Information Needed
Business Function
Technical Platform
People Resources
Business Model
Inventory
Guidelines / Standards
A pictorial representation
FEA Reference Models
Business-Driven Approach
• Inputs, outputs, and outcomes
• Uniquely tailored performance indicators
Business Reference Model (BRM)
• Lines of Business
• Agencies, customers, partners
Service Component Reference Model (SRM)
• Service domains, service types
• Business and service components
Data Reference Model (DRM)
• Business-focused data standardization
• Cross-agency information exchanges
Technical Reference Model (TRM)
• Service component interfaces, interoperability
• Technologies, recommendations
Component-Based Architecture
Performance Reference Model (PRM)
So what is in a TSA Document?






Objectives
Opportunities
Gaps
Key Issues & Performance – Current State
Key Requirements – Target State
3-5 Year Recommendation – Transition State
Assess what
the business
needs
Identify
Current State
Identify Target
State
Prioritize and
define transition
state
Keep it simple – 1-2 pages each
Opportunities
GAPS
Target State
Objectives
Current State
(Picture if Possible)
Transition Process
Time for a break

Come back for a live example
<< Business or I.T.
Name of Process >
Target State Architecture
Outline






Name of Process Architecture Objectives
Name of Process Architecture Opportunities
Name of Process Architecture Gaps
Key Issues & Performance – Current State
Key Requirements – Name of Process Target
3-Year Recommendation – Transition State
Name of Process TSA Objectives

Bullet 1


Bullet 2


The bullets on this page are to emphasize the
business or technology challenges you are trying to
impact
Should be specific, in business terms and
measurable
Bullet 3
Name of Process Architecture
Opportunities




The items on this slide should be specific
projects / Initiatives coming up that would
afford a change to your environment
Bullet 2
Bullet 3
etc
current state
Key Issues & Performance

List of specific current business pains and
performance
target state
Key Requirements (Specific examples
of requirements)
Ex:




Reduce number of originating sources
Define information authority / stewardship
Cease proliferation of new data streams
Explore methods to support corporate Information library.
transition state
Transition State – 3-Year
Recommendation
Deliverable
Cost
Benefit (H/M/L)
Upgrade
Estimated FTEs: 1.5
Estimated Time (months) 9
Estimated Capital
Customer Sat. M
Economic Impact L
Complexity M
Strategic Alignment L
to Application X,
Y, Z from
Hardware:
none
Software: none
Reporting
Estimated FTEs: 5
Estimated Time (months): 6
Estimated Capital
Customer Sat. H
Economic Impact M
Complexity H
Strategic Alignment M
w/LMN project
Estimated FTEs: 2
Estimated Time (months):24
Estimated Capital: NA
Customer Sat. H
Economic Impact H
Complexity H
Strategic Alignment H
Consolidated
Partnering
Transition State – 1+ Yr recommendation
2005
2H05
2006
1H06
Initial Product Data Inventory
Define Product Governance
2007
2H06
1H07
2008
2H07
1H08
2H08
Quality: Standard Repository
Governance: Establish Product Data Ownership and Stewardship
Decommission Legacy Systems
Build Corporate Product Catalog/ Data Dictionary
Quantity: Reducing number of product sources
Quality: Provide a single authoritative
source of product information (metadata)
Target State – 3-5+ Yr recommendation
(can use similar diagramming tool)
Architecture Long Range Plan
Developing architectural capabilities of an IT organization takes sustained
effort over a long period of time.
2006
2008
2010
2012
2014
Fully developed enterprise
& Technology architects,
Architects in the business
People
Local technology experts
Technology Architects &
(EA) Enterprise Architects
Process
Defined process for
localized efforts
Evolve Enterprise
Processes
Standardize enterprise and
local processes
AD Hoc & locally chosen
application technology
Standardized application
technologies
Streamlined and lean
application technologies
Loose Infrastructure
Architected Infrastructure
Optimized Infrastructure
Business Unit Independent
un-integrated Silos
Integrated applications &
Shareable business
processes
Lean and Standardized
Technical and business
processes
Technology
Results
Additional References / Info






Putting Data back into Data Architecture, by Jane Carbone, TDan online newsletter
http://www.tdan.com/i021hy04.htm
See also the DAMA Presentation that Jane did for Dama - Seattle, June 2005, http://www.drmaseattle.org/JCJune2005.ppt
Where the Target Application Architecture TAA Rubber meets the Road , Bureau of Land
Management, http://www.blm.gov/ba/spotlights/spotlight10.htm
Systems and Software Consortium - http://www.software.org/pub/architecture/feaf.asp
Federal Enterprise Architecture Website, http://www.whitehouse.gov/omb/egov/a-1-fea.html
Zachman Institute for Framework Advancement, http://www.zifa.com
Thanks for your time and interest!

Dawn Michels







Enterprise Information Architect
Past Pres DAMA MN
Past VP Chapter Services DAMA-I
Adjunct Faculty Member, College of St.
Catherine
Passionate Data Architect
Dawn.michels@Andersencorp.com
651-264-7985
Download