Date post: | 18-Aug-2015 |
Category: |
Documents |
Upload: | mark-goetsch |
View: | 26 times |
Download: | 0 times |
Moving from Applications to the Enterprise
Mark GoetschEnterprise Software Architect
Wheels
Speaker• Enterprise Software Architect and Chief of the Architectural Council
with Wheels.• 15+ years in Software Development.• Last 5 ½ years as either a Software, Business, Data or Enterprise
Architect.• UML author for DevX.com.• Given talks at Enterprise Architects Summit, Midwest Software
Engineering Conference and Research Seminars at DePaul University.
• Founding member of the WWISA (World-Wide Institute for Software Architects) and a Director and Board member for the Business Architects Association.
Prerequisites
• Enough experience in development that you can drive code from concepts.
• Have worked in or seen environments where multiple applications are interfaced with one another – even if done poorly.
Plan of Attack!
1. History of Software Development up to the Enterprise
2. The Software Portfolio and how it is constructed
3. How to Breakdown a Silo
4. Layering the Enterprise
1. The History
Functions, Structures, Objects, Components all leading to the
Enterprise
It Started with Instructions
Functions Appeared
Added Data to the Functions
Object Orientated AD was Born
There Appeared Components
This Became the Enterprise
Which does not Protect us from Silos!
Questions?
• Started with Instructions
• Added Functions
• Used Data Structures to add Processes
• Objects let us vary the Processes
• Components used Interfaces
• …There is the Enterprise
2. The Software Portfolio
Aligning IT with Business
What is the Portfolio?• The enterprise is all of the software that
provides services to the business. We refer to this software as the software portfolio.
• How the software portfolio maps against the business defines the IT view of the enterprise.
Software Portfolio
Vertical Integration
Horizontal Integration
Service-Oriented Architecture
Service Bar
Example of using the Software Portfolio Matrix
Creating Enterprise Communications
The Inbound/Outbound Matrix for Wheels
Software Portfolio Matrix
VOTR Collision
Inbound Fax OCR
FaxeMail
Outbound Letters LettersSpell Check
Add Horizontal Integration
Software Portfolio Matrix
VOTR Collision
InboundOCRFax
OutboundLetters
Spell Check
Combining into the Enterprise
What are the Results?
• We save costs on replicated software and hardware.
• We have one standard for each function of the enterprise.
• We can add the same facilities to the other business units.
Questions?
• I looked at Vertical Integration
• I introduced Horizontal Integration
• I talked about SOA
• …and we had an example
3. Breaking Down Silos
Moving from the Software Portfolio to a Technical
Implementation
How to Break Down Silos
1. Find the right split for the service bar.
2. Create two sets of domains: a solution domain and a problem domain.
3. Convert the service bar into services.
4. Enforce domain barriers to answer solution domain questions.
Domain Service Bar
What are Domains?
• Problem domains answer the question on “How the firm does business?”
• Solution domains will answer the question on “How does the firm implement how it does business?”
Note on Terminology
Solution Domain
Application
Problem Domain
Domain
Problem: We might have multiple tasks rather than an application in the Solution Domain.
Architectural Domains
Using Domains to Answer Questions
• If a solution domain wants to know the answer to a question such as “Who is the driver of the vehicle” or “What vehicles does the driver use” this would use different problem domains.
“Business will find the patterns they need from an architectural handbook. If they [business] don’t use this handbook then they will not be able to stay in business”
Ralph Johnson
Speech on the Architectural
Handbook given at DePaul University, 2003
Using Domains to Answer Questions
• “What Vehicles does the Driver use” will only use the Driver domain.
• “Who is the driver of the vehicle” will only use the vehicle domain.
• Never Cross Problem Domains.
What if there are no Boundaries?• Dependencies
between Domains develop.
• The Services become hardwired to a particular object configuration.
• We develop yet another Silo although it might be unique to one service.
How to Separate Problem Domains
(Horizontal Separation)
Rules for Separation• Each domain should have almost no
associations between the support objects.• If a support class needs to be maintained
between the two domains it may be a composite/integration object, may represent a new domain or need to be replicated for each domain.
• There can only be one main domain object per domain that can access all the support objects.
• Each main domain object that is in the another domain needs to be replicated.
Without Domain SeparationVehicle
Replacement Parts
Registration
Driver
Accidents
License
After Domain Separation
Vehicle: Vehicle
Vehicle:Replacement
Parts
Vehicle:Registration
Driver:Driv er
Accidents
Driver:License
Driver: Vehicle
Vehicle:Driver
What does this do for us?
• From an application level probably not much.
• From an enterprise level we can have a common reference point for any object.
• We can support different views of the same object related to different domains.
• We avoid horizontal silos.
Separation between Problem and Solution Domains(Vertical Domains)
Two Intertwined DomainsSheets Sheet
OptionCalculator
+ Volatil i ty: float+ Time: int+ InterestRate: float+ UnderlyingPrice: float+ StrikePrice: float+ StepSize: float
+ CalculateBlackScholes() : float+ CalculateBlackScholesImpliedVolatil ity() : float+ CalculateCRR() : float+ CalculateCRRImpliedVolatil i ty() : float+ CalculatePropModel1() : float+ CalculatePropModel2() : float+ CalculatePropModel1ImpliedVolatil ity() : float+ CalculatePropModel2ImpliedVolatil ity() : float
SheetsConfiguration
SheetConfiguration
The Solution DomainSheets Sheet
Nodes
NodeRow
Frame
«enumeration»Internationalization
+ United States: Country+ United Kingdom: Country+ Germany: Country
International
Configuration
The Problem DomainNodes
Node
+ Delta: float+ Gamma: float+ Theta: float+ Vega: float
«interface»OptionModel
+ CalculateOption() : double+ CalculateImpliedVolatil ity() : double+ LoadModel() : void
TreeModel
+ ModelName: int+ Time: int+ Volatil ity: float+ UnderlyingPrice: float- StrikePrice: float+ StepSize: float
+ CalculateOption() : double+ CalculateImpliedVolatil ity() : double+ LoadModel() : void
ClosedFormModel
+ ModelName: int+ Time: int+ Volatil ity: float+ UnderlyingPrice: float+ StrikePrice: float
+ CalculateOption() : double+ CalculateImpliedVolatil ity() : double+ LoadModel() : void
«enumeration»ModelName
- CRR: int- BlackScholes: int- PropModel1: int- PropModel2: int
How Does this Help Us?
• We have reusability of Common Services.
• The Separation from the Processing of the Data and How the Data is used is clean.
• Even though it looks more complicated there is now maintainability and it is easier to test and be reliable.
Questions?
• There are Solution Domains
• Which use Services
• From Problem Domains
• Problem Domains should not Communicate with each other.
4. Layering the Enterprise
Moving from Domains to Layers
What is a Tier?
A tier is a point of hardware variation. Tiers however may not be implemented but represent the scalability concerns of an architecture.
Architecture Layers/Tiers
What is a Layer?
• Layers represent logical boundaries.
• Each layer is a separate concern – this is referred to as “separation of concerns”
• Only use delegation between layers – never inheritance
Adding Layers to the Tiers
Resolving the Layers
Problem #1: Inheritance Across Layers
Problem #1: Inheritance is Contained
Problem #1: Integrate into Enterprise
Problem #2: Separation of Concerns
• The consumer uses and object to call some lower level services.
• Even though the instance of the object exists with the consumer the object the consumer does not know or care about its functionality.
Problem #2: Separation is Violated• The object is
promoted to the consumers layer.
• To access the objects functionality the consumer must have the same inheritance hierarchy as the object.
• Welcome to your first Silo!
Problem #2: Can Only Pass Object• Consumer
instantiates object as type object.
• Cannot use the object directly.
• Must pass it down into a lower layer to be used.
• Takes extra time.
Example of the Breaking Down of a Silo in the
Financial Markets
Original Layering
Separate into Problem and Solution Domains
Add Services
Add some Utilities
The Final Enterprise Layers
Results…
• We were able to generate scenarios and positions in less than 30 sec. from 15 min. This allowed us to access our positions and risk in the marketplace throughout the day.
• The solution domains were simpler to replicate which knocked down development time from 6 months to move into a new market to under 2 weeks.
Winding Down…
• We covered the history of software development, how it turned into silos, how to see those silos using a portfolio matrix, how to break the silos and finally how to layer the enterprise to avoid silos.
• We showed examples of how to use the portfolio matrix and how silos were broken down with a financial trading application.
Final Questions?
• Speaker: Mark A Goetsch
• Email: [email protected]
• Shameless plug for my UML articles on devX.com