2. 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.
3. 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.
4. 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
13. 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
15. 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.
25. 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.
26. Questions?
• I looked at Vertical Integration
• I introduced Horizontal Integration
• I talked about SOA
• …and we had an example
27. 3. Breaking Down Silos
Moving from the Software
Portfolio to a Technical
Implementation
28. 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.
30. 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?”
33. 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.
34. “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
35. 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.
36. 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.
38. 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.
40. After Domain Separation
Vehicle: Vehicle
Vehicle:
Replacement
Parts
Vehicle:
Registration
Driv er:Driv er
Accidents
Driv er:License
Driv er: Vehicle
Vehicle:Driv er
41. 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.
44. The Solution Domain
Sheets Sheet
Nodes
NodeRow
Frame
«enumeration»
Internationalization
+ United States: Country
+ United Kingdom: Country
+ Germany: Country
International
Configuration
46. 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.
47. Questions?
• There are Solution Domains
• Which use Services
• From Problem Domains
• Problem Domains should not
Communicate with each other.
49. 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.
51. 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
57. 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.
58. 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!
59. 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.
60. Example of the Breaking Down of
a Silo in the
Financial Markets
66. 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.
67. 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.
68. Final Questions?
• Speaker: Mark A Goetsch
• Email: mgoetsch@AgileArchitecting.com
• Shameless plug for my UML articles on
devX.com
