Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Microsoft PowerPoint ...


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

Microsoft PowerPoint ...

  1. 1. PROCESS PERFORMANCE MANAGEMENT Business Process Modeling Product Knowledge Customer Balanced Scorecards Design Mgt Mgt Consultants “Pot Searc Company-Wide Scorecard entia h and l Contact updat Vacan mat candidate e Performance Measure Performance Measure Performance Measure cy ch” facilit aware Inputs Client ness Y Available and interested? y Inputs Acquire Content Edit e (vacancies) s Interview by consultant Y N o Feedb ack Candidates (CVs) Content Mgt Content e Performance Measure Performance Measure Performance Measure Interview by Account Job posting s client manager mechanism Database Re Database manager jec Acc t Offer made ept to candidate N Performance Measure Performance Measure Performance Measure o Job taken Y Create Distribute Y Take job?e N Outputs e s o Content Content s People Business Technology LOCATIONS Dvlpmt Mgt Mgt TECHNOLOGY Facilities, Distribution, Physical Assets Information, Applications, Infrastructure Architecture Views P ro d uc t K n o w led g e C u s to m e r PEOPLE D e sig n M gt M gt Organisation Design Siebel D a ta A cq u is itio n Vignette C o n te n t M gt E d it C o n te n t C re ate P rod u ct WebSpheree D istrib u te P ro du ct P e o p le D v lp m t SAP B u s in e ss M gt T e ch n o lo g y M gt Enterprise Architecture as Business Capabilities Architecture Ruth Malan, Dana Bredemeyer Raj Krishnan and Aaron Lafrenz Bredemeyer Consulting Tel: (812) 335-1653 Fax: (812) 335-1652 Email: Inquiries: Web: Acknowledgments We would like to thank Raj Krishnan who inspired and championed the Business Capabilities Architecture as the cornerstone of our approach to Enterprise Architecture. He recognized the centrality of capabilities, and drafted our Enterprise Visual Architecting Process (E-VAP) using capabilities as the organizing theme. We have taken that initial work and advanced it, used it with clients, and moved the whole frontier forward, but Raj deserves credit for the inspiration and genesis of the capabilities approach that we promulgate. Aaron LaFrenz, too, was instrumental in moving us into the Enterprise Architecture space. His ideas and energy have had a great impact on our work, and we are much indebted to his influence. Copyright © 2002-2006 Bredemeyer Consulting 1
  2. 2. Introduction • Current state/desired state for IT • Convergence of evolutionary paths of Organization Design and Enterprise Architecture • Enterprise Architecture as the architecture of business capabilities Copyright © 2002-2006 Bredemeyer Consulting Enterprise Architecture as Business Capabilities Architecture May 7, 2003 Slide 2 Copyright © 2002-2006 Bredemeyer Consulting 2
  3. 3. Common Current State for IT Inconsistent, duplicated Change in competitive islands of data landscape Inhibits, Inhibits, Brittle, monolithic constrains, Business strategy applications constrains, frustrates frustrates Business processes Rigid, inflexible technical infrastructure dis Technology-enabled business capabilities • Rigid, brittle, aging systems • Functional silos with insular pockets of system development and procurement • Bottom-up technical decision-making Copyright © 2002-2006 Bredemeyer Consulting Enterprise Architecture as Business Capabilities Architecture May 7, 2003 Slide 3 “If the Federal Government continues to do what we’ve done (build non-architected solutions), we will continue to get what we have – a non-interoperable, expensive and ever- challenging tangle of data, applications and technology.” - Source: FEAF Version 1.1 IT Status Quo The current state of IT, if allowed to persist, will result in maintenance of the status quo--with its rework, ever decreasing productivity, and lost opportunities. For the Federal government, it would mean failure to comply with the Clinger-Cohen Act, and for industry, it would mean that competitors who adopt EA (and succeed in overcoming the organizational challenges) will have significant strategic advantage over those who do not. Copyright © 2002-2006 Bredemeyer Consulting 3
  4. 4. Desired State for IT Strategic Agility Enabled by Technology trigger trigger Change in Change in Change in competitive Enterprise business landscape Strategy processes and enabling systems early identification short strategy adaptive processes planning cycles and enabling technology “business intelligence” Copyright © 2002-2006 Bredemeyer Consulting Enterprise Architecture as Business Capabilities Architecture May 7, 2003 Slide 4 Strategic Agility The length of business cycles has decreased over the past two decades--the fast-paced cycles are being called “hypercompetition.” Businesses have to be able to identify and respond to changes in the competitive landscape. Increasingly, these changes have to do with technology, which underpins innovations not just in products, but in services and value delivery, either directly or through the application of technology in innovative ways. Copyright © 2002-2006 Bredemeyer Consulting 4
  5. 5. Enter Enterprise Architecture • Enterprise Architecture has been widely embraced as the route to this desired state Enable integrated business intelligence Connect strategy to execution Enable flexibility and adaptability, so that business capabilities can keep pace with changes in strategy Copyright © 2002-2006 Bredemeyer Consulting Enterprise Architecture as Business Capabilities Architecture May 7, 2003 Slide 5 Purpose of Enterprise Architecture • Enterprise architecture provides a common basis for understanding and communicating how systems are structured to meet strategic objectives • Instead of allowing a single solution (Custom or COTS) to drive the technology, EA provides a balanced approach to the selection, design, development and deployment of all the solutions to support the enterprise • Enterprise architecture allows stakeholders to prioritize and justify often conflicting technology trade-off decisions based on the big picture • Enterprise architecture leads to consolidation and simplification; more disciplined approaches to system planning, funding and development; better risk management with fewer false starts (Malan and Bredemeyer, June 2005). Copyright © 2002-2006 Bredemeyer Consulting 5
  6. 6. Rising Awareness of Enterprise Architecture • Clinger-Cohen Act of 1996 US Federal and State Agencies and Departments • DCI, Gartner and Cutter have Enterprise Architecture Conferences or Summits • Gartner and Cutter have Enterprise Architecture Practice Areas • Open Group’s TOGAF Copyright © 2002-2006 Bredemeyer Consulting Enterprise Architecture as Business Capabilities Architecture May 7, 2003 Slide 6 Clinger-Cohen Act 1996 The Clinger-Cohen Act (see holds each Federal Agency CIO responsible for developing, maintaining, and facilitating the implementation of an information technical architecture. One of the outcomes is the Federal Enterprise Architecture Framework (FEAF) that the Federal CIO Council began developing in 1998 and issued in 1999. Copyright © 2002-2006 Bredemeyer Consulting 6
  7. 7. Examples of Enterprise Architecture In the Public Domain • Agencies of the US Federal and State government FEA: Federal Enterprise Architecture • On the web site! NASCIO: Enterprise Architecture Development Toolkit, v. 3, 2004 HUD Case Study CMS Enterprise Architecture • TOGAF Case Studies • Dairy Farm Group (Hong Kong) • Department of Social Security (UK), Ministry of Defence (UK), National Health Service (UK), Police IT Organization (UK) • Litton PRC (US) • NATO (Belgium) • Westpac (Australia) Copyright © 2002-2006 Bredemeyer Consulting Enterprise Architecture as Business Capabilities Architecture May 7, 2003 Slide 7 Federal and State Enterprise Architectures The US Federal government and various State agencies have made a fair amount of their Enterprise Architecture Resources (especially their Enterprise Architecture Frameworks, but also at least parts of their Enterprise Architectures). These include: Centers for Medicare and Medicaid Services Enterprise Architecture HUD’s EA Practice: HUD has various EA resources, including the Single Family Housing (SFH) case study, available on their web site at According to HUD, “implementation of the SFH blueprint will reduce the number of SFH systems by nearly 80 percent—from 30 supported and 6 unsupported systems to approximately 7 core modules. The SFH blueprint minimizes functional overlap, and reduces the total cost of ownership by modernizing the technology base and decreasing maintenance costs.” A SFH case study presentation is available on the web at TOGAF Case Studies The Open Group Architectural Framework (TOGAF) maintains an overview and links to material on the application of TOGAF in the creation of Enterprise Architecture on Copyright © 2002-2006 Bredemeyer Consulting 7
  8. 8. What is Enterprise Architecture? Defining Characteristic • The defining characteristic that differentiates Enterprise Architecture from other architectures is: enterprise scope • it crosses (internal) organizational boundaries e.g., – covers multiple business units – crosses functional boundaries Why would we do anything across the scope of the enterprise? It creates opportunities and allows problems to be tackled that cannot be effectively dealt with at a “lower level”, i.e., a more narrow scope e.g., increase collaboration so that we can decrease duplication across business units so that we can save on development costs Copyright © 2002-2006 Bredemeyer Consulting Enterprise Architecture as Business Capabilities Architecture May 7, 2003 Slide 8 Enterprise Architecture Scope Creates Opportunities--and Challenges By working across organizational boundaries such as different business units and functional groups, Enterprise Architecture allows the business to address issues such as shared access to information and reduced redundancy in development, hence lower costs. These are things that cannot be addressed in organizational “silos” or “islands.” However, every time you work across organizational groups, and the more diffuse these groups are in their vested interest, the challenges inherent in organizational acceptance, politics, commitment, etc., go up by orders of magnitude! That is why we pay so much attention to these issues in our process (the Enterprise Visual Architecting Process or E-VAP) and in our Role of the Architect section. Why not Centralize Everything? Why not Decentralize Everything? Every large organization has had its pendulum swings from increasing fragmentation into customer-focused units to more integration across related market segments. We know from bitter experience that each has its costs and benefits. More fragmentation but higher market segment focus leads to higher customer intimacy and innovation around the customer but increases duplication, inconsistency and integration problems. On the other hand, more integration leads to higher synergies across the business but dilutes customer intimacy and tends to slow innovation. Enterprise Architecture cannot simply be another pendulum swing towards centralized control. Bear in mind that Nash talks about collaboration, not centralization. Also, we can’t do everything as a joint effort! We have to ask “Why do this at the enterprise level?” What does it gain us? What does having that gain us? Is this an enterprise priority? Can we get this by some other means? We have to pick strategically where to focus enterprise-scope, collaborative activity. Copyright © 2002-2006 Bredemeyer Consulting 8
  9. 9. Evolving Definition of Enterprise Architecture • The definition of Enterprise EA = ETA Architecture has been evolving Technology Architecture alone was not sufficient to address enterprise IT goals like “a EA = EWITA single view of the customer” Enterprise IT Architecture alone is not sufficient to ensure business/IT alignment EIA EAA ETA EA = BA + EWITA Copyright © 2002-2006 Bredemeyer Consulting Enterprise Architecture as Business Capabilities Architecture May 7, 2003 Slide 9 Evolution of the Notion of Enterprise Architecture Part of the difficulty in coming up with a shared definition of Enterprise Architecture arises from the fact that our notion of Enterprise Architecture is expanding. EA = TA (Technology Architecture) Much of the early Enterprise Architecture work focused on enterprise-wide Technology (or infrastructure) Architecture efforts -- this includes early work by META Group and TOGAF. Projects using this narrow concept of EA focused on establishing technology standards and principles, and often extended to attempts to inventory the various technologies in use in the corporation (capturing the “as-is architecture”). EA = EWITA (Enterprise-wide IT Architecture) It became clear that the goals of EA efforts had to be tackled on a broader front, encompassing Information and Application Architecture, not just Technology Architecture. This would allow the EA team to go after problems like “single view of the customer” and reducing redundancy across projects by improving application portfolio management. EA = BA + EWITA (Business Architecture + Enterprise-wide IT Architecture) Recent work (e.g., Paul Harmon at Cutter, META Group, and a number of federal agency EA projects) emphasizes the importance of including BA in the EA definition. Don’t be fooled though. A “Business Architecture” produced by an IT team may document business objectives and business processes and function, but is unlikely to be the active design and implementation of changes to the business process and structure. Since the business side of the organization has the charter to structure their people and process, IT is not going to be very effective in imposing process designs and structural changes on them. Copyright © 2002-2006 Bredemeyer Consulting 9
  10. 10. Evolving Definition of EA Broader Scope, Higher Potential Value Value EA = BA + EWITA Enhance Business/IT Alignment EA = EWITA Enhance Value EA = TA Management Reduce IT cost and enhance operations Scope Copyright © 2002-2006 Bredemeyer Consulting Enterprise Architecture as Business Capabilities Architecture May 7, 2003 Slide 10 Increasing the scope of EA Increasing the scope of EA to encompass more disciplines, increases the benefits to be gained. EA = TA EA = EWITA EA = BA + EWITA Reduce IT complexity and Support collaboration among Increase enterprise agility costs: different parts of the and alignment with - increased convergence enterprise: business strategy consolidates purchasing, - shared access to information across the business and, - enable changes in lowers training costs, business strategy with increases employee increasingly, from outside the business by customers, quick-response changes in mobility in the enabling processes and organization partners, suppliers, even competitors technology solutions - elimination of duplication in - inform strategy more similar applications for effectively, because there is different business functions a strategic path for or different business units identifying and integrating - address concerns that cut technology-enabled across business units, such opportunities (and threats) as integration, interoperability, and security Cynical view: Shaped by vested interests, EA grew to take on the maximum significance implied by the name. Alternative view: the full, multidisciplinary scope of EA is necessary to achieve what strategic management really want from technology investments. Copyright © 2002-2006 Bredemeyer Consulting 10
  11. 11. Evolution of Organizational Design • Organizational design has also progressed through a series of “revolutions” functional specialization business process reengineering enterprise architecture Copyright © 2002-2006 Bredemeyer Consulting Enterprise Architecture as Business Capabilities Architecture May 7, 2003 Slide 11 Copyright © 2002-2006 Bredemeyer Consulting 11
  12. 12. Organization Design Hierarchies and Silos • Silo Design CEO developed functional silos with functionally-specialized process Mktg Mfg Fin. HR and procedure efficiencies in the silo • independence within the islands BUT inherently fragmented • Relies on the management requires heroism at the hierarchy for communication and interfaces! control customer-centered processes are inherently cross-functional Copyright © 2002-2006 Bredemeyer Consulting Enterprise Architecture as Business Capabilities Architecture May 7, 2003 Slide 12 Hierarchy and Organizational Design The spirit of this style of organizational design persists, even if it is no longer the vogue to strictly organize around functional specialties. You will constantly see re-organizations where a new CEO is marched in, the company is re-organized into a new bunch of silos with new names and new chiefs. The silo specializes around its own cluster of internal concerns, because it is driven by a hierarchy. Copyright © 2002-2006 Bredemeyer Consulting 12
  13. 13. Enter Business Process Re-engineering • BPR recognized that processes crossed functional lines have to pay attention to process across the historical divides to make order of magnitude improvements BUT ignored the force of technology it constrains as much as it enables! Copyright © 2002-2006 Bredemeyer Consulting Enterprise Architecture as Business Capabilities Architecture May 7, 2003 Slide 13 Business Process Re-engineering BPR reaped results for some companies, and was a big resource sink for others, raising tremendous organizational antibodies in the wake of failed attempts. Organizational change and process design takes attention and resources. The other important illumination was recognizing that technology constrains and frustrates the process if you ignore its force and do not shape technology to support the process and shape the process to be aligned with technical capabilities. For example, if you purchase someone else’s Enterprise System (ES) you will find that you either have to change your process or the system will change your process for you. Copyright © 2002-2006 Bredemeyer Consulting 13
  14. 14. Evolutionary Paths Converge at Enterprise Architecture • Organizational design and Enterprise Architecture have converged because we cannot ignore technology in business process design we cannot ignore the business in technology solution design Copyright © 2002-2006 Bredemeyer Consulting Enterprise Architecture as Business Capabilities Architecture May 7, 2003 Slide 14 Copyright © 2002-2006 Bredemeyer Consulting 14
  15. 15. Enterprise Architecture and Business Capabilities Business Architecture • Enterprise Architecture = the architecture of business (business capabilities) Information Business processes Org. Structure capabilities cross-cutting concerns need to design business EWITA capabilities EIA EAA ETA people cross-cutting concerns process and technology Copyright © 2002-2006 Bredemeyer Consulting Enterprise Architecture as Business Capabilities Architecture May 7, 2003 Slide 15 Enterprise Architecture and Business Capabilities Enterprise Architecture recognizes that the organization is a system, and the cross-cutting concerns must be addressed first at the overall system level. It recognizes that you cannot solve every detailed problem at once--you cannot hold complex systems entirely “in your head”. You need to find effective ways to decompose the problem. Focusing on business capabilities that support business strategy, first, then delving into the design of those capabilities, forms an effective way to consider people, process and technology together. Capability versus Process Design Process design focuses on activities to produce outcomes. Capability design includes process design, and adds technology to the consideration. This has become vital as technology is a broad reaching enabler in all kinds of industries. We can see this best by reference to an example. While SAP systems have clearly been successfully integrated into a number of businesses, there have also been failures. You hear of executives taking over declining companies, “ripping out SAP, and turning the business around within a year”. Why do enterprise systems like SAP fail in some companies yet succeed in others? Clearly, the interrelationship between technology and process, skills and culture was not taken into account. Taking on an enterprise system that requires broad-scoped process changes in a company that is not ready for them (or doesn’t even recognize they are needed) is a recipe for disaster. Capabilities are not processes--a process delivers a capability using a mixture of people, technology, and location. The focus of capability design is on the outcome and the effective use of resources to produce a differentiating capability or an essential supporting capability. Copyright © 2002-2006 Bredemeyer Consulting 15
  16. 16. Business Capabilities • Business capabilities may be Technology (data, applications, inherent in people/process only infrastructure) (manual) • very few left these days provided by fully automated Performance systems • not too common in most industries People People Process Process (organization, CAPABILITY (activities, produced by a collaboration knowledge, sequence, between people and technology skills, culture) inputs, in technology-enabled processes outputs, • create more efficient and effective constraints) processes Assets • enable innovation through better (facilities, access to information, enhanced resources) productivity or by acquisition by purchasing technology solutions Copyright © 2002-2006 Bredemeyer Consulting Enterprise Architecture as Business Capabilities Architecture May 7, 2003 Slide 16 Capabilities as the Focus of Enterprise Architecture Business capabilities are a combination of business processes, people (organization, knowledge and skills, culture), technology solutions, and assets (facilities, funds, etc.) aligned by strategic performance objectives. Capabilities, in this approach, are the building blocks of the enterprise. They have relationships to each other and to the environment, and we need to pay attention to these interfaces, and to be clear on what responsibilities are being assigned to a capability. Together, people, process, technology and performance management yield a capability that has quality characteristics. These quality characteristics are important in driving the capability design process, just as in any other kind of architecture. Copyright © 2002-2006 Bredemeyer Consulting 16
  17. 17. EA as Business Capabilities Architecture What Does it Look Like? TV Pressure External Influences Regulators Government Competitors Groups Core Business Suppliers Customers Manage Manage Manage Hardware Suppliers Services Brand Television Programs Acquire Distribute Manage Customers Content Content Customers Movies Website Manage Content Content Manage People Manage Technology Internet Other Portals Channels New Entrants and Substitutes Diagram contributed by Raj Krishnan Consulting Copyright © 2002-2006 Bredemeyer Enterprise Architecture as Business Capabilities Architecture May 7, 2003 Slide 17 Conceptual Enterprise Architecture A Business Capabilities Architecture may not look a whole lot different than a high-level business process architecture! Where business processes are the driving force for the capability, they will show up on the business process architecture. However, capabilities as the building block are more general. Fundamental capabilities will focus more on skills and competencies (e.g., positioning architecture as an organizational competency). Capabilities may be acquired as enterprise systems (see Davenport’s Mission Critical: Realizing the Promise of Enterprise Systems, 2000); that is, they may be heavily technology-based, with ramifications for business processes, skills and culture. Each capability may have a driving concern (process, technology, skills, culture, assets), but each must take the other facets into account, and each relates to other capabilities in some way. See Each capability now becomes a unit of design. If the capability is primarily a process, then the Business Architect may lead its design, collaborating with relevant IT architects in doing so. If the capability will be supplied primarily by some technology solution, then IT Architects (Applications or Solution Architects, or perhaps Infrastructure/Technology Architects) will lead the design of that capability. Strategies and the capabilities that enable them, can thus be iterated on at various levels in the organization, providing an effective approach to implementing business strategy. Acknowledgment: This slide derives from a slide that Raj Krishnan and Aaron LaFrenze introduced into the first version of our EA workshop. Copyright © 2002-2006 Bredemeyer Consulting 17
  18. 18. Business Capabilities Architecture The Natural Next Step After Strategy Context Competitive Strategic Strategy Business landscape, Analysis Setting Capabilities Value partners, Business context Identity and People, Process, Industry and Differentiating Value Technology and and business technology drivers Propositions Assets required trends • Context Map • Strategy Map • Business Capabilities • Industry Structure Map • Business objectives Architecture • Opportunity Assessment • Strategic initiatives • Gap analysis • Business Vision • Balanced Scorecard • Capability Roadmap • Strategic Gameplan Copyright © 2002-2006 Bredemeyer Consulting Enterprise Architecture as Business Capabilities Architecture May 7, 2003 Slide 18 Capabilities Create the Link to Business Strategy Business capabilities can be directly tied to business strategy, creating a mechanism to very directly connect Enterprise Architecture to Business Strategy. This is the goal that CEOs and CIOs have been identifying as a top priority, but it was illusive when the focus was on technology in isolation (IT architecture heritage), or process in isolation (BPR heritage). Capabilities also form a natural way to cascade objectives from a strategic to tactical level. Acknowledgment: This slide derives from a slide that Raj Krishnan and Aaron LaFrenze introduced into the first version of our EA workshop. Copyright © 2002-2006 Bredemeyer Consulting 18
  19. 19. The Dance of Change Identity Value Proposition Business Strategy Capabilities Business Strategy is Current EA refined in the informs next Business TV Pressure generation EA External Influences Regulators Groups Government Competitors Core Business Strategy Suppliers Manage Manage Manage Customers Hardware Suppliers Services Brand Television Programs Acquire Distribute Manage EA as Customers Content Content Customers Movies Business Website Manage Content Content Capabilities Manage People Manage Technology Architecture Internet Other Portals Channels New Entrants and Substitutes Copyright © 2002-2006 Bredemeyer Consulting Enterprise Architecture as Business Capabilities Architecture May 7, 2003 Slide 19 Relating Strategy and EA Enterprise Architecture is the foundation for and implementation of Business Strategy. Critical Role of Architecture Architects translate business strategy into technical strategy and lead the implementation of that strategy. Technical capabilities of companies has become a pervasive foundation for competitive advantage even in industries that are not “so-called” high-tech industries. Any strategy that relies on technical capabilities, must be translated into technical strategy terms, to create the link between the business strategy and the execution of that strategy by the development community. Also, architects have the background that gives them the best insight into technical capabilities and trends, and their engagement in the business strategy process is the best way to ensure that business Without Architecture: Without architecture, all the individual decisions of developers are not aligned. In today’s decentralized organizations, with high value being (appropriately) placed on individual creativity and contribution, everyone makes strategic decisions as part of their day-to-day job. Without architecture to guide and align these decisions, however, these decisions tend to be at odds and the whole is not greater than the sum of the parts. With Architecture: Architecture is what provides the context for all the individual technical decisions to be aligned with the vision and strategic direction. It is what provides focus and leverage, and concentration of energy, powering the technology capability essential to execution of the business strategy. Copyright © 2002-2006 Bredemeyer Consulting 19
  20. 20. Business Strategy to Enterprise Architecture Business Capability Capability Capability Enterprise Architecture Strategy A B C Capabilities Enterprise Architecture Architecture Business Architecture Business strategy Which What capabilities capabilities will need to be Cap D differentiate our built at Information Architecture business? enterprise scope? Applications Architecture Infrastructure Architecture Copyright © 2002-2006 Bredemeyer Consulting Enterprise Architecture as Business Capabilities Architecture May 7, 2003 Slide 20 Distinction Between Business Strategy and Enterprise Architecture Strategy Business strategy elaborates on the business vision, sets the direction for the business, and picks where to focus executive attention. It identifies high-level initiatives in support of strategic themes, expressed in strategic business objectives. Enterprise Architecture strategy elaborates the EA vision and refines business strategy objectives, and determines where to focus the attention of the enterprise-scoped, multi- disciplinary EA effort. It • sets scope (which capabilities to focus on) • refines and elaborates strategic themes within that scope • sets objectives for the Enterprise Architecture effort Architectural Strategy The architectural strategy is a set of high-level decisions that will strongly influence the integrity and structure of the system, but is not itself the architecture of the system. Through vision, objectives, principles, philosophy, etc., the architectural strategy rules certain structural choices out, and guides selection decisions and trade-offs among others. By stating principles that are repeatedly applied across the architecture, a consistent approach is ensured and this simplifies the architecture. It is also very useful at this stage, to find a metaphor or organizing concept that works for your enterprise. It will help you think about the qualities that the architecture should have, it may even help you think about what pieces you need and how they relate (in Conceptual Architecture), and it will certainly help you make the architecture more vivid and understandable. Copyright © 2002-2006 Bredemeyer Consulting 20
  21. 21. References Books • Maier, M. and E. Rechtin, The Art of Systems Architecting, CRC Press, 2002. • Rechtin, E. Systems Architecting: Creating and Building Complex Systems. Prentice-Hall, 1991. • Spewak, S. H., Enterprise Architecture Planning, Wiley, 1992. Enterprise Architecture as Business Capabilities Architecture May 7, 2003 Slide 21 Papers • Bredemeyer, Dana, and Ruth Malan, “What it Takes to be a Great Enterprise Architect ”, Cutter Consortium Enterprise Architecture Report, August 2004 • Kruchten, Philippe, “Common Misconceptions about Software Architecture”, The Rational Edge, April 2001 • Malan, Ruth and Dana Bredemeyer, “Enterprise Architecture as Strategic Differentiator”, Cutter Consortium Enterprise Architecture Report, June 2005 • Malan, Ruth and Dana Bredemeyer, “Minimalist Architecture”, 2002 • Malan, Ruth and Dana Bredemeyer, “Strategy Primer for Architects”, 2003 • Malan, Ruth, and Dana Bredemeyer, "Enterprise Architecture: Balancing Centralization and Decentralization", April 2003. Copyright © 2002-2006 Bredemeyer Consulting 21
  22. 22. Resources Web Sites • Resource Sites (with papers, links, etc.) Global Enterprise Architecture Organisation: Resources for Architects site: • Enterprise Architecture Project Sites Department of Commerce IT Enterprise Architecture Home Page NASCIO's Adaptive Enterprise Architecture Development Program Resources Enterprise Architecture as Business Capabilities Architecture May 7, 2003 Slide 22 Other Sites of Interest • World-wide Institute of Software Architects (WWISA) web site: • SEI web site: There are many sites that are highly useful to Enterprise Architects in that they cover Enterprise Architecture. In this list, we have focused on sites that relate to the Architect. Copyright © 2002-2006 Bredemeyer Consulting 22
  23. 23. Enterprise Architecture Communities and Organizations • Other major influences to pay attention to Gartner Group: Enterprise Architecture practice Cutter Consortium: Enterprise Architecture Executive Reports • EA communities Global EA Organization (GEAO): The Enterprise Architecture Network Enterprise Architecture Interest group: • DCI/Shared Insights Enterprise Architecture Conference Copyright © 2002-2006 Bredemeyer Consulting Enterprise Architecture as Business Capabilities Architecture May 7, 2003 Slide 23 Architecture Essays, Discussion Boards, Blogs and Blog Entries EA Glossary blog on egov.blogs Enterprise Architecture blog on egov.blogs GotzeBlogged: Blogging eGovernment from EA to eDemocracy Architect's Linkblog Ruth Malan's Trace in tbe Sand Architecture Journal, Ruth Malan's Trace in the Sand blog IBM developerWorks Architect blogs: - Ali Arsanjani Best practices in Service-Oriented Architecture - Grady Booch Software architecture, software engineering, and Renaissance jazz - Sanjay Bose SOA, ESB, and beyond - Alan Brown Exploring model-driven development - Chris Ferris Web services, distributed computing, and interoperability - Don Ferguson Middleware and tools - Anant Jhingran Information Management Technology Directions and Trends - Simon Johnston Service-Oriented Architecture and business-level tooling - Rich Schwerdtfeger Accessibility strategy and architecture Christopher Koch's (CIO Magazine) IT Strategy Blog frequently deals with EA/related topics Copyright © 2002-2006 Bredemeyer Consulting 23
  24. 24. Training • Bredemeyer Consulting offers the following classes Enterprise Architecture Workshop (4 days) • Chicago, September 12-15, 2006 Enterprise Architecture Seminar (1 day) Role of the Architect Workshop (3 days) Software Architecture Workshop (4 days) See for more information on our training and consulting services Enterprise Architecture as Business Capabilities Architecture May 7, 2003 Slide 24 About Bredemeyer Consulting Bredemeyer Consulting provides a range of consulting and training services focused on Enterprise, System and Software Architecture. We provide training and mentoring for architects, and typically work with architecture teams, helping to accelerate their creation or migration of an architecture. We also work with strategic management, providing consulting focused on developing architectural strategy and organizational competency in architecture. Copyright © 2002-2006 Bredemeyer Consulting 24