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

eMail

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: mgoetsch@AgileArchitecting.com

• Shameless plug for my UML articles on devX.com