Enterprise Architecture Patterns a rollercoaster ride

1
Enterprise Architecture Patterns- a
rollercoaster ride

• by
• Michael A. Beedle Ph. D.
• Principal
• Framework Technologies

2
Outline

• Introduction
• Patterns
• Enterprise Architecture Patterns
• Pattern Based Reengineering
• Conclusions

3
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

4
Predictability
Predictability vs. Knowledge (J. Casti -
Searching for Certainty)
5
Business as CAS

• CAS complex adaptable systems, John Hollands
  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

6
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.

7
(No Transcript)
8
Zachmans Framework
9
(No Transcript)
10
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.

11
Business Architecture Team

• Business Architect, Business Architecture Client
  Teams, etc.
• Copliens org patterns, etc. (Size the
  Organization, Developer Controls Process,
  Architect Controls Product, Conways Law,
  Organization Follows Market, Alexanders
  patterns, etc.)
• Berczuks, Cunninghams org patterns, etc.

12
Software Architecture

• Application Follows Process
• Reify the Process
• Shared Business Objects
• ACE (adaptive computing environment, Doug
  Schmidt)
• PLOP123, etc.
• POSA (Pipes and Filters, MVC, Blackboard, etc.)
• GOF patterns (Adapter, Factory Method, Prototype,
  Facade, Iterator, Visitor, etc.)

13
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 dont 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.

14
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.

15
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.

16
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

17
(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

18
Life Cycle
19
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/OrgP
  atterns?ProjectIndex

20
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.