Upload
others
View
9
Download
0
Embed Size (px)
Citation preview
© Michael Rosen 2007 Slide 1
Implementing Enterprise
Architecture with MDA
Michael Rosen
Chief Technologist
Wilton Consulting Group
© Michael Rosen 2007 Slide 2
Mike Rosen
Consultant• SOA, EA and MDA modeling, implementation, strategy and training• Chief Architect for service-oriented systems
– Finance, Insurance, Telecom
• IT Architecture and Strategy• 25+ years experience in distributed systems, software and architecture
Affiliations• Cutter Consortium – Director of Enterprise Architecture• SOA Institute – Editorial Director, SOA Conference Co-chair
Author• Cutter Consortium
– “Designing Service Oriented Applications”– “EA – It’s not Just for IT Anymore”– “Agile Methods and Enterprise Architecture”– “Enterprise Architecture Roll-out and Training”– “Service Oriented Integration: Aligning SOA with Enterprise Integration”– “Implementing SOA on Common Technologies”– “An Application Centric Approach to Enterprise Architecture”
• Applied SOA: Architecture and Design Strategies, Wiley, due 2008• Developing e-Business Systems and Architecture: A Manager’s Guide, 2000,
Morgan-Kaufman• Integrating CORBA and COM Applications, 1998, Wiley
© Michael Rosen 2007 Slide 3
Agenda
What is EA?
MDA Process
Implementing EA with MDA
Case Study
Conclusion
© Michael Rosen 2007 Slide 4
What is Enterprise Architecture?
The primary goal of Enterprise Architecture is to align presentand future IT systems with business goals and strategy
Typical technology goals are:• Establish interoperability between systems
• Provide consistently stable technology
• Implement cost-effective standard infrastructure, leverage existinginvestments
• Maximize benefit to the business through appropriate reuse of technology
Business and architecture goals are:• Reduce IT expenditures
• Support IT portfolio management
• Support outsourcing
• Provide framework for enterprise IT governance
EA is about enabling change and managing complexity
© Michael Rosen 2007 Slide 5
WebGo Telecom Portal
© Michael Rosen 2007 Slide 6
Architecture — The Immediate Need
Let’s assume all of the external systems for WebGo exist. Whilebuilding WebGo, we would need certain information
The first Architectural-Level needs for WebGo are:• How the WebGo Portal will connect to those systems?• How it will communicate (protocol)?• How it will understand data (formats, meaning)?
The next Architectural-Level issues are understanding of theprocess WebGo implements:• What users can do?• What level of security is there?• What amount of automated process is there?
Then as we turn WebGo on:• What scale of usage was introduced?• What about reliability of the integrated systems?• What about operating (supporting) this new portal?
© Michael Rosen 2007 Slide 7
Architecture — The Broader Need
The previous slide did not describe a very broad view.There are additional considerations:
• How does WebGo support a business strategy?
• How will we measure the success of that?
• What of WebGo was already implemented in the enterprise?
• Did we just add a redundancy?
• What technologies did we introduce, and what is their supportcycle?
• What did WebGo tell us about the various data models in the back-end systems?
• When WebGo becomes “WebGone”, are there components orservices that can be re-assembled to make “WebGo++”?
The immediate needs described application architecture
• Application Architecture is part of EA, but it is not the same as EA
© Michael Rosen 2007 Slide 8
Design: Describes specific
items and relationships,
Applies to a single product
or application.
E W
Enterprise Architecture:
Describes concerns and guidelines
for integration of process and data
across the entire enterprise.
Applied to many application domains.
Application Architecture:
Describes abstract concepts,
things and relationships within
the application domain.
Applies to many products
or applications.
E1 W1 Wn
Architecture Scope
© Michael Rosen 2007 Slide 9
WebGo Portal Architecture in Detail
Drives
Service
Provisioning
Driven by SLA &
Assurance Driven by Billing
Driven by
Marketing
Driven by Fault
Mgmt System
Driven by
CRM System
Several
Diverse
Systems
involved
© Michael Rosen 2007 Slide 10
Customers Employees SuppliersOther
Partners
Web Portal
PersonalizationContent
Management
ERPLegacy
SystemsCRM
Packaged
Apps
SecurityKnowledge
Management
Corporate
Data
Application
Platform and
Application
IntegrationWorkflow Rules
WebGo Portal “Conceptual Architecture”
Channels
Portal
services
Applications
and resources
© Michael Rosen 2007 Slide 11
Application Platform
WebGo Implementation Slice
legacysystemsCustomer
ExistingFunctions
ExistingFunctions
Portal
© Michael Rosen 2007 Slide 12
.
.
.
user enterpriseworkspace resource
Authorization
Service
Configuration
Service
BPM
Service
Logging
Service
Profile
Service
Persistence
Service
WebGo Application Architecture
application
services
infrastructureApplication Services Platform
Resource
Adapter
Business
Entity
packagedapplication
Business
Process
Component
Work
Coordinator
View
ControllerPresentation
legacySystem
Application
Adapter
Business
Composition
User
ProfileSession
© Michael Rosen 2007 Slide 13
Application Architecture
Describes how to build systems that meet specificapplication requirements
Describes how to:
• Create consistent applications across the enterprise
• Use technical architecture
• Configure and manage applications
Includes
• Architectural elements
• Fundamental product elements
• Common construction patterns
• User model
• Application frameworks
© Michael Rosen 2007 Slide 14
user enterprise
packagedapplicationResource
Adapter
Business
Entity
workspace resource
Business
Process
Business
Composition
Business
Document
Processing
Message
Handling
legacySystem
Application
Adapter
Business ProcessingServices
WebServiceServices
XMLServices
infrastructure
application
Web Services Architecture
Web Services Platform
services
© Michael Rosen 2007 Slide 15
Business Processing
Web Service
Web Interface
user enterprise
packagedapplicationResource
Adapter
Business
Entity
workspace resource
Business
Process
Business
Composition
Business
Document
Processing
Message
Handling
legacySystem
Application
Adapter
Combined Architecture
Work
Coordinator
View
ControllerPresentation
User
ProfileSession
services
© Michael Rosen 2007 Slide 16
user enterpriseworkspace resource
services
infrastructure
application
Architectural Foundations
Underlying technical and communication capabilities
Common utility functions applied across tiers
Application level business logic
Tiers
Layers
Presentationand device
independence
User sessionand data
manipulation
Businessprocesses
and entities
Sharedenterpriseresources
© Michael Rosen 2007 Slide 17
WebGo Deployment View
: Firewall
External : Workstation
Internal : Workstation
Primary WS : Web Server : Security Server
: Directory Server
: Database Server
Primary AS : Application Server
Primary RS : Reporting Server
: ETL Process Server Reduntant RS : Application Server
Redundant RS : Reporting Server
Redundant WS : Web Server
Planned for a future release ... not in scope for release 1.
Enterprise Interwoven Environment
Primary : Content Manager Redundant : Content Manager
: File Server
HTTPSHTTPS
HTTPS
HTTPS
HTTP HTTP
LDAP
LDAP
JDBC
ODBC
ODBC
JDBC
LDAP
ODBC
CAM Process
CAM Process
© Michael Rosen 2007 Slide 18
Technical Architecture
Describes how to build systems that meet specific technicalrequirements
• Non-functional requirements
• Enterprise “abilities”
• Architectural qualities
Describes standards, products, protocols and technologies
Includes
• Architectural layers
• Distribution tiers
• Infrastructural services
© Michael Rosen 2007 Slide 19
Customer Usage & Quality
Project/Process Management
Network Research & Quality
Network Infrastructure Assets
ForecastingNetwork/Product
Planning
CapitalEquipment
Acquisition
ConstructionNetwork
Monitoring
Primary
Activities
Core
Business
Process
Process
Management
Quality
Management
Product
Information
Customer
Order
Service
Provisioning
Customer
Service
Customer
Billing
Real-time
Operations
“… to provide a premium
communications network
and customer services”
telecom
network
customer
service
Goal
Supporting (Financial, HR, IT, …) Assets
HR Management
Financial Management
IT Management
Administration Management
Supporting
Activities
Support Asset
Info
Supporting
Processes
Business Architecture — Value Chain
© Michael Rosen 2007 Slide 20
Business Architecture
Understand and describe the underlying Business ValueChain within the enterprise
Understand and describe fundamental business processes
Link business strategies to business processes
Leverage technology to align business process strategieswith IT initiatives
Understand the gap between business process “as is” and“to be” environments. Identify a transition strategy.
© Michael Rosen 2007 Slide 21
Enterprise Architecture Revisited
A set of architectures, which taken together, provide acomplete view of an organization.
Conforms to architectural principles, especially Separationof Concerns:• Business
• Information
• Application
Architecture must achieve three primary goals:Describe a solution to a specific set of problems and requirements.
Effectively communicate the solution to all stakeholders.
Enable the construction of systems that conform to the architecture.
• Technical• Operations• Implementation
© Michael Rosen 2007 Slide 22
Enterprise Architecture
Technical
Architecture
TechnicalRequirements
Application
Architecture
ProgramRequirements
Architecture-Driven Design
Operational
ArchitectureOperationalRequirements
Deployed
Service
EnterpriseRequirements
ApplicationRequirements
Application
Analysis and Design
Implementation
ArchitectureImplementationRequirements
Application
Implementation
Business
Architecture
Business
Requirements
Information
Architecture
InformationRequirements
© Michael Rosen 2007 Slide 23
MDA Distilled
Computation Independent
Model
Business Analyst
Platform Independent
Model
Architect / Designer
CodeDeveloper / Tester
Platform SpecificModel
© Michael Rosen 2007 Slide 24
MDA Mappings
Computation Independent
Model
Platform Independent
Model
Code
Platform SpecificModel
PIM PIM Mapping
PIM PSM Mapping
PSM PSM Mapping
PSM Code Mapping
© Michael Rosen 2007 Slide 25
MDA Under the Hood
Computation Independent
Model
Platform Independent
Model
Code
Platform SpecificModel
Enterprise QOS and
non-functional
requirements
implemented in
transformations
Architectural
Standards and
Guidelines Enforced
in Model Profiles
© Michael Rosen 2007 Slide 26
Metamodels
Provide rules for how to build a correct model for a particular purpose, e.g.“business integration metamodel”
UML Profile
• Provides a targeted subset of UML
• Standard mechanism for extending UML
Refinement and Constraint
• Metamodels refine the definition of modeling elements by placing constraints ontheir behavior through the use of stereotypes
Stereotypes
• Standard UML Stereotypes– <<boundary>>, <<control>>, <<entity>>
• Extending the UML Stereotypes– Inheritance used to extend and refine the meaning of stereotypes
– Tagged Values use to apply specific properties
© Michael Rosen 2007 Slide 27
.
.
.
user enterpriseworkspace resource
Authorization
Service
Configuration
Service
BPM
Service
Logging
Service
Profile
Service
Persistence
Service
WebGo Application Architecture
application
services
infrastructureApplication Services Platform
Resource
Adapter
Business
Entity
packagedapplication
Business
Process
Component
Work
Coordinator
View
ControllerPresentation
legacySystem
Application
Adapter
Business
Composition
User
ProfileSession
© Michael Rosen 2007 Slide 28
Metamodel Stereotypes
service
application service
<<stereotype>>
domain service
<<stereotype>>
business service
<<stereotype>>
presentation controller
<<stereotype>>
application session
<<stereotype>>
business entity
<<stereotype>>
boundary
<<stereotype>>
ER controller
<<stereotype>>
IT service
<<stereotype>>
presentation client
<<stereotype>>
Class Diagram: Metamodel /
Metaclass Interactions
session contextdata
session process
control
<<stereotype>>
state
{transient} {long lived}
Behavior
entity
<<stereotype>>
{persistent}
{state
composi
contro
Usage
Scope and
visibility
Location and
purpose
Standard UML
Stereotypes
Courtesy Terry MerrimanCourtesy Terry Merriman, ©2003
© Michael Rosen 2007 Slide 29
Presentation Tier Application Tier
Enterprise Tier
IT Services
Resource Tier
Metaclass InteractionsER controller
Control the state and relationships among entities()
business service
Expose business functionality()Call domain services to do the processing()
Aggregate results of Domain Services()
system entity
Persists data beyond a session()
Has behavior specific only to its internal state()
state/relationship
verification/propagation
composition control
Technology Resource
RDBMS
Rules Engine
Transaction Monitor
etc.
presentation client
Display information()
Receive user's input()
External Systems preferred
domain service
Process domain specific algorithms()
Control resouces of the domain()
Visible only within the domain()
discouraged
requests of
other domains
domain service
requests
information
retrieval/update
IT service
Security
Logging
Profiling
Persistence
Transactions
etc.
Control access to technology()
technology requests
technology
requests
interaction with
technology
products
presentation controller
Format data for presentation()
Control local navigation()
send user
input
post
updates
application service
Access back end services()
Performed shared application logic()Expose application logic()
discouraged
domain service
requests
IT service requests
application session
Control the flow of the user session()
Massage data for viewing or processing()forward user
interactions
send data to user
request
process ing
Web Architectural Style Metamodel
“Rules of Engagement”
Courtesy Terry Merriman, ©2002
© Michael Rosen 2007 Slide 30
MDA Profiles
Computational Independent Model• Business-oriented non-UML representation. Simplified UML subset
appropriate for business analysts.
Platform Independent Model• Custom profiles for enterprise architecture and standards
• Standard based profiles (EDOC, EAI)
Platform Specific Model• Standards based profiles (CORBA, EJB, .NET)
© Michael Rosen 2007 Slide 31
MDA Process Revisited
Computation Independent
Model
Business Analyst
Platform Independent
Model
Architect / Designer
CodeDeveloper / Tester
Platform SpecificModel
MDA Architect
© Michael Rosen 2007 Slide 32
Computation Independent
Model
Platform Independent
Model
Code
Platform SpecificModel
Technical
Architecture
Application
Architecture
Business
Architecture
Each Profile formally
specifies a particular
architecture
Business Model
<<UML Profile>>
Application Model
<<UML Profile>>
Platform Model
<<UML Profile>>
Architecture Profiles
© Michael Rosen 2007 Slide 33
MDA
Enterprise Architecture
Technical
Architecture
TechnicalRequirements
Application
Architecture
ProgramRequirements
Architecture-Driven Design
Operational
ArchitectureOperationalRequirements
Deployed
Service
EnterpriseRequirements
ApplicationRequirements
Application
Analysis and Design
Implementation
ArchitectureImplementationRequirements
Application
Implementation
Business
Architecture
Business
Requirements
Information
Architecture
InformationRequirements
© Michael Rosen 2007 Slide 34
EA and MDA Summary
Enterprise Architecture involves separating concerns intoviewpoints
Specific architectural viewpoints are formalized in profilesand metamodels
Profiles enforce application conformance to enterprisearchitecture
MDA provides a standards-based approach to definingprofiles and using the profiles to help automatedevelopment
© Michael Rosen 2007 Slide 35
Case Study
Large US Insurance Company
$25 Billion USD
~ 20 Lines of Business
Enterprise Architecture Group exists
…with little to no effect
…ARB Exceptions at 80%
No consistency across design
Little to no reuse
Redundant functions and data
IT costs too high
IT time-to-market to slowMaintenance
Integration
New Applications
© Michael Rosen 2007 Slide 36
What we did
Institute an architecture based / MDA approach
Create a set of UML Profiles that specify the enterprisearchitecture
Integrate the UML Profiles into a modeling framework builtwith Rational Rose and REI
Tie the Software Architecture Specification to theFramework
Create documentation: User Guide, Modeling Guide,examples
Create education program: Architecture, Modeling,Framework
Ramp up the number of application architects. Focus themon assisting projects
© Michael Rosen 2007 Slide 37
APSL Enterprise Process
Define the approach• Integrate enterprise architecture into the
development process.
Create meta-models and profiles
Define the problemCreate Business Models (Domain, CIM,
System)
Define the solutionRefine into PIMs and PSMs
Leverage the results• Integrate assets into a reuse repository
• Architecture and design accommodates: reuse,
customization, enhancements, versioning…
Define the Approach
Define the Problem
Define the Solution
Leverage the Solution
Co
nti
nu
ou
s F
eed
bac
k
Iterative D
evelo
pm
ent
© Michael Rosen 2007 Slide 38
Rose Framework for Application Architects
Define theApproach
Define theSolution
Define theProblem
© Michael Rosen 2007 Slide 39
Enterprise Architecture
Technical
Architecture
Application
Architecture
Operational
Architecture
Implementation
Architecture
Business
Architecture
Information
Architecture
Approach Definition Views
Architectural
Development Services
Architectural
StylesFoundational
Services
Frameworks Patterns Technology
Mapping
© Michael Rosen 2007 Slide 40
Enterprise Architecture
Technical
Architecture
Application
Architecture
Operational
Architecture
Implementation
Architecture
Business
Architecture
Information
Architecture<project name - problem space>
<<Focus Package>>
Business
Analysis ModelBusiness View
Business Use
CasesBusiness Process
Models
Business Information
ModelBusiness
Domain Model
Problem Definition Views
© Michael Rosen 2007 Slide 41
Enterprise Architecture
Technical
Architecture
Application
Architecture
Operational
Architecture
Implementation
Architecture
Business
Architecture
Information
Architecture
Solution Definition
Logical Architectural ViewOperational View
<project name - solution space><<Focus Package>>
Application System Analysis High Level Design Model Structural View Deployment ViewsProcess View
Solution Definition Views
© Michael Rosen 2007 Slide 42
Logical Architecture
The Logical Architecture is a result of Application Analysisand the application of patterns
Verifies that business requirements are addressed
Confirms architectural alignment
Identifies services
• Consumed
• Produced
Reflected in the Model and the Software ArchitectureDocument
© Michael Rosen 2007 Slide 43
Software Architecture Document
The SAD is a communication tool that
• Ties together business needs, application development,domain / enterprise views within a project
• Keeps scope within application area, but with anenterprise architectural underpinning
• Helps integrate with other projects/areas
• Is an important physical deliverable
• Is a poor choice of acronym…
© Michael Rosen 2007 Slide 44
Basic Approach to SAD Modeling
Use the SAD Rose framework to create your model and todocument the elements in the model
Use the SAD SoDA template to create a project templatefor extracting information from the model and documentingsections of the SAD not placed in the model
• Don’t forget to update the File / Properties
Generate the SAD report
SoftwareArchitecture
Spec.
© Michael Rosen 2007 Slide 45
Challenges
Adoption
• Overcome skepticism about architecture
• Change behavior of software organization
• Win over business sponsors
When is an architect done?
• Don’t get sucked into implementation
• Logical architecture level
• Preliminary SAD – 4 weeks, SAD – 10 weeks
Ramp-up• Where do you get all the architects?
• Grow architects from within
• Develop project criteria
© Michael Rosen 2007 Slide 46
New EA Organization
LOBArchitects
EnterpriseArchitects
SpecificationsModelsFrameworksInfrastructure
SolutionsPatterns
AnalysisDesign
ReviewBoard
EA Program
Business
Information
Application
TechnologyInfrastructure/ Operations
Services
Central ITBusiness
Units
Projects
TaxonomyRepositoryMaintenanceProject MgmtEnhancements
Assigned To
ConsultingArchitects
© Michael Rosen 2007 Slide 47
Results
Consistency• SADs have same structure and format across projects• Project architectures have the same logical structure, roles and responsibilities• Allows for comparison between projects• Enables standard technology platforms
Reuse• Opportunities for reuse more easily identified• Component ~reuse up 200%
Usage• Used for all ‘App Architect’ projects• Increasing adoption of LOB architects and designers
Demand• 5 architects first year• 25 architects 2nd year, 50 architects 3rd year• 500 projects get architects…1000 others wich they could
Exceptions• Compliance up 500% for applications with architects, review process streamlined• Exceptions down to 10% for projects with architects
© Michael Rosen 2007 Slide 48
Architecture Value Proposition
Alignment of IT systems with business goals and strategy
Improved customer satisfaction
Consistency across applications
Reduced costs to implement, maintain, evolve, and retireapplications
Improved IT operations• Common semantics and information
• Interoperability between applications
• Integration of applications
• Reuse of infrastructure, frameworks, utilities
© Michael Rosen 2007 Slide 49
User Interfaces
Improving Productivity and Consistency
CustomInfrastructure
Architecture
CustomProcesses
Businessservices, processes
and entities
Tools
User Interfaces
Infrastructureand processes
Architecture
Tools
Businessservices, processes
and entitiesCost of a
new
application
Dramatically
reduce costs
by utilizing
existing IT
assets
Typical applicationToday
Built mostly from scratch
Infrastructureand processes
Existing
New
Key: High productivityTomorrow
Built on an existing foundation
Each
application
needs
the same
parts. Don’t
build
them all
each time.
© Michael Rosen 2007 Slide 50
Parallel Paths of Technology and
Application
Application Architect
Application Design tomeet Business Functionality
Technology Architect
Infrastructure Design tomeet QoS Requirements
Implementation
Deployment
© Michael Rosen 2007 Slide 51
The Importance of Early Knowledge
Courtesy: Cutter Fellow Ken Orr
time
exp
en
dit
ure
expenditures committed
domain/technology knowledge
project costs
© Michael Rosen 2007 Slide 52
Thank You!
“Every complex problem has a solution that is clear,simple…and wrong”
— H.L. Mencken, 1949