Framework
Technologies
Enterprise Architecture Patterns
- “a rollercoaster ride”
by:
Michael A. Beedle Ph. D.
Principal
Framework Technologies
Outline
Introduction
Patterns
Enterprise Architecture Patterns
Pattern Based Reengineering
Conclusions
Introduction
What is success? Profitability, Predictability,
Efficiency, Human Comfort, Hyper-Productivity,
Adaptability, Knowledge Creation, Intellectual
Capital, etc.
Business Success:
– Customers Driven, Process, Organizational Structure,
Culture, Sound System Architecture, Leadership
Personal Success:
– Skills, happiness, enjoyment, freedom, comfort,
habitability
Predictability
K Celestial Mechanics
n
o
w
le
d
War
ge
Business Management/Software Development Management
Quantum Mechanics
Economics
Predictability
Predictability vs. Knowledge
(J. Casti - Searching for Certainty)
Business as CAS
CAS = complex adaptable systems, John Holland’s
“Hidden Order”, SFI, etc.
Aggregation = Team Structures
Nonlinearity = of Knowledge, Information, Energy,
Resources, etc.
Flows = Knowledge, Information, Energy, Resource
exchange
Diversity = Of people, machines, languages, cultures, etc.
Tags = Identification of roles, authority, power, resources
Internal Models = beliefs, plans, visions, etc.
Building Blocks = learned and emergent PATTERNS
Pattern Sources
Business Architecture: TQM, BPR, Learning Organizations,
Knowledge Management, Kaizen, MBWA, One minute
management, 7 Habits, Empowerment, Applied “I Ching”,
etc.
Software Architecture: Client/Server, OO Development, Data
warehousing, Patterns, 4GLs, Java, INTERNET technologies,
Object/Relational Databases, RAD, JAD, UML, etc.
Business Organization Leader
Core Processes
Case of Action
Business Vision Statement
Architecture
Process Owner
Organization Learning
Organization
Business Architect Encourage
Other Business Workflow Patterns ProductiveValues
such as Haugen's, Jablonski and Strategic
Map Existing Direction Initiative
Business and Bussler 's, and Meszaros and Brown's,
New Business
Systems etc.
and Systems Integrate Customers
Architecture Architecture And Suppliers
Process With Minimal
Organization Checks and Controls
FollowsProcess
Business Multiple Process Versions
Scenarios Define Architecture
Business Process Team
Flat Structure Process With Minimal
Reconciliation
Sub-Architect
Case Application
Business Architecture Client Business Process Engineering a org-patterns Coach
Teams such as Beedle's, Hammer's, Jacobson's, Case Worker
Meszaros and Brown's, and Taylor's, etc.
Compreses the Case Team
Process
Software Development Organization Case Manager
Application Development org patterns such as:
Anderson's, Appleton's, Berczuk 's, Coplien's, Cockburn's, ApplicationFollowsProcess
Cunningham's, Harrison's, Risng's, Delano's, SCRUM and
Whitenack's, etc.
Software Architecture
Reify the Process
SharedBusiness
Released Baselines Objects
Other Workflow Architecture patterns /constructs
such as Beedle's, Haugen's, Jablonski and
Bussler's, and Meszaros and Brown's, etc. Other Software Architecture
patterns such as GOF, POSA, etc.
Model Office
Zachman’s Framework
Business Patterns
Leader
Core Processes
Case of Action
Vision Statement
Process Owner
Organization Follows Process
Integrate Customers and Suppliers
Coach, Case Workers, Case Teams
etc.
Business Architecture Team
Business Architect, Business Architecture Client Teams,
etc.
Coplien’s org patterns, etc. (Size the Organization,
Developer Controls Process, Architect Controls Product,
Conway’s Law, Organization Follows Market, Alexander’s
patterns, etc.)
Berczuk’s, Cunningham’s org patterns, etc.
Software Architecture
Application Follows Process
Reify the Process
Shared Business Objects
ACE (adaptive computing environment, Doug Schmidt)
PLOP1+2+3, etc.
POSA (Pipes and Filters, MVC, Blackboard, etc.)
GOF patterns (Adapter, Factory Method, Prototype,
Facade, Iterator, Visitor, etc.)
Core Processes
Alias - Value Streams, Business Process Focus
Context - To make decisions at the business strategy level the fundamental business
architecture of the organization must be determined.
Problem - What is the best way to model the organization and think about its problems and
goals?
Forces - Financial views are too narrow to understand deep problems.
- Cultural approaches to the understanding of the organization reveal causes but don’t give
solutions
Solution - Create a short description of the Core Processes of the organization which are key to
understand what is important to the organization and its customers. This will allow the
organization to tie the people oriented aspects of the company to the financial results of the
company from the view of “operations”.
Resulting Context - Once the Core Processes of the organization are determined it is
necessary to evaluate them.
Example - TI processes are: Strategy Development, Product Development, etc.
DeveloperControlsProcess
Context - An imperfectly understood design domain, where iteration is key to development.
Forces - Totalitarian control is viewed by most development teams as a draconian measure. The right
information must flow through the right roles. You need to support information flow across analysis,
design, and implementation.
- Managers have some accountability.
- Developers should have ultimate accountability, and have the authority and control of the product; these
are often process issues.
Solution - Place the Developer role at a hub of the process for a given feature. A feature is a unit of
system functionality (implemented largely in software) that can be separately marketed, and for
which customers are willing to pay. The Developer is the process information clearinghouse.
Responsibilities of Developers include understanding requirements, reviewing the Solution structure
and algorithm with peers, building the implementation, and unit testing. Note that other hubs may
exist as well.
Resulting Context An organization that supports its prime information consumer. The Developer can be
moved toward the center of the process using patterns WorkFlowsInward, and MoveResponsibilities.
Though Developer should be a key role, care must be taken not to overburden it. This pattern should
be balanced with MercenaryAnalyst, FireWalls, GateKeeper, and more general load-balancing
patterns like BuffaloMountain.
Shared Business Objects
Problem- Lack of conceptual integrity in the System Architecture across business processes.
Solution - An OO Enterprise System Architecture makes it possible to share business objects
not only as "building blocks" for the development of applications but even as a "live cache"
of business objects that are reusable for many applications. Some products in the market
like Persistence, are able to do this by wrapping relational databases (INFORMIX, Oracle,
SYBASE or SQL Server) as business objects, allowing many advantages such as: increase
performance (up to 250 times as fast as relational databases), iterative incremental
development and co-existence with legacy systems.
Examples
Boeing BPR effort, Motorola Iridium, Nike Securities, Hewitt Associates (and most other OO
architectures), and most other CORBA implementations.
Pattern Based Reengineering
Alexanderian paradigm of
Architecture
1. The principle of organic order
2. The principle of participation
3. The principle of piecemeal growth
4. The principle of patterns
5. The principle of diagnosis
6. The principle of coordination
(continued)
Business Analysis (Business Requirements Model)
Business Design (Business Process Model)
– Systems Analysis (Enterprise System Architecture
Requirements Model)
– System Architecture (Enterprise System Architecture)
– Application Implementation (Executables)
Business Evolution
Business Maintenance
Life Cycle
Strategic
Assesment
Business
Analysis business
evolution business
Business
Design design
Business Cy cles ov er small:
Assessment
business
Evolution Analy sis
Design
analysis
Deliv ery
Business strategic
Process assesment
Delivery
Conclusions
We are just getting started
We have achieved some modest successes
There is a wealth of patterns that have not been mined and
synergized as of this date
The future points to “Enterprise Architecture Patterns”
Check out:
http://www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns?ProjectIndex
Future Directions
•Growing community of users
•Growing community of writers
•Team of CPL (common pattern language) architects
at ChilliPLOP98
•More integration with system architecture patterns
•More integration with SCM (software configuration
management) patterns
•Mine more org patterns domains
•Blend in emerging patterns of distributed agents and
electronic commerce, etc.