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

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

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.

8. Zachman�s Framework

10. Business Patterns

11. Business Architecture Team

12. 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.)

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

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/OrgPatterns?ProjectIndex

20. Future Directions