A Practical Guide to Enterprise Architecture (The Coad Series) / Edition 1

Paperback (Print)
Buy Used
Buy Used from BN.com
$38.23
(Save 41%)
Item is in good condition but packaging may have signs of shelf wear/aging or torn packaging.
Condition: Used – Good details
Used and New from Other Sellers
Used and New from Other Sellers
from $1.99
Usually ships in 1-2 business days
(Save 96%)
Other sellers (Paperback)
  • All (19) from $1.99   
  • New (7) from $46.78   
  • Used (12) from $1.99   

Overview

In A Practical Guide to Enterprise Architecture, six leading experts present indispensable technical, process, and business insight into every aspect of enterprise architecture. You'll find start-to-finish guidance for architecting effective system, software, and service-oriented architectures; using product lines to streamline enterprise software design; leveraging powerful agile modeling techniques; extending the Unified Process to the full software lifecycle; architecting presentation tiers and user experience; and driving the technical direction of the entire enterprise. For every working architect and every IT professional who wants to become one.

Read More Show Less

Product Details

  • ISBN-13: 9780131412750
  • Publisher: Prentice Hall
  • Publication date: 10/28/2003
  • Series: Coad Series
  • Edition description: New Edition
  • Edition number: 1
  • Pages: 306
  • Product dimensions: 7.00 (w) x 9.25 (h) x 0.82 (d)

Meet the Author

JAMES McGOVERN, Enterprise Architect for Hartford Financial Services, is a co-author of the bestselling books Java Web Services Architecture and Agile Enterprise Architecture. SCOTT W. AMBLER, senior consultant with Ronin International, specializes in O-O analysis/design, agile modeling, and architectural audits of mission-critical systems. His best sellers include Agile Modeling and The Elements of Java Style. MICHAEL E. STEVENS, Software Architect for Hartford Financial Services, is a columnist for Developer.com. He co-authored Java Web Services Architecture. JAMES LINN, consultant at Hartford Technology Services, co-authored XQuery Kick Start. VIKAS SHARAN is managing partner of Lozoic and architecture team member at Baypackets. ELIAS JO, Systems Architect for The New York Times Digital, has architected and/or led development at DeutscheBank, Citibank, Standard & Poor, and ADP.

Read More Show Less

Read an Excerpt

Preface

In today's business climate, the rules of competition have changed. Organizations are forced to eliminate the process of reinventing the wheel each time a new business problem arises that forces the enhancement of an existing system or implementation of a new one. Enterprise architecture is the practice that allows organizations to build foundations they need to survive and adapt to present and future business challenges. Sound enterprise architecture supports the ability to stay agile, provides for increased return on investment, and creates a framework for making future technology decisions.

Enterprise architecture identifies the main components of an organization and how components in the organization's nervous system function together to achieve defined business objectives. These components include personnel, business processes, technology, financial information and other resources. If decisions about components and their interrelationships are uncoordinated, minimally effort and resources will be duplicated; performance and management problems will arise and will result in the loss of agility. Enterprise architecture done correctly will ensure the choice of appropriate components and will specify how each component will operate together in a fluid manner that increases organizational efficiencies.

Enterprise architecture is one of the most challenging roles in information technology today. Many aspects of the role are technical while much more of it is about interaction. Many people who have this position have significant responsibility but do not have authority or control. Enterprise architecture as an area of study allows one to focus on interesting,complex problems, to advance on the corporate ladder, and to maintain technical competencies while making a colossal difference to the enterprise.

Enterprise architecture requires skill sets not normally taught in university curriculum or acquired on the job. Even good architectures are rarely accepted without formidable challenges. The successful architect has to overcome any aversion to politics and become the evangelist of architecture in the eyes of its various stakeholders. Architects cannot simply buy into any vision that is articulated. Any involvement in the implementation of enterprise architecture requires one to understand it. The most successful architecture will have an architect that can describe the motivation behind architectural choices. Likewise, a successful architecture has an architect who leads the architecture team, the development team, the technical direction of the enterprise, and sometimes the organization itself. The primary focus of this book is to be a guide and trusted advisor to those who want to be successful in this role.A wise enterprise architect once worked for a very well-respected organization (name intentionally withheld). He was passionately engaged in a conversation with a senior executive about what direction the organization should take with its information systems. His recommendations fell on deaf ears until he asked the executive three very simple questions:


  • How can we have a viable customer relationship management strategy when we do not even know where all of our customer's data reside?
  • How does our technology spending equate to enabling our strategic business goals?
  • Does our organization have an operational process model?

As you can surmise, the answers to these questions were not known. Many executives in information technology are not knowledgeable about what it takes to guide the architecture in the direction that results in the biggest bang for the buck. Sadly, many executives have lost control of the ship they steer, which has resulted in bloated infrastructures and conclusions being made on whims rather than on sound principle-based judgment and experience.In many organizations, the annual budget cycle starts with clueless, disruptive questions such as "How many servers do we have?" or "Let's get the new Intel 3333 GHz machines as desktops." None of these statements is appropriate for a discussion about enterprise architecture. A good architecture addresses the following:

  • The organization's business and information needs
  • Leverage of the synergistic relationship between return on investment (ROI) and total cost of ownership (TCO)
  • The ability to support migration from the current state (as-is)
  • The ability to support easy migration to the organization's desired future state
  • Ways to support the business objectives of reducing costs, improving operational service, and increasing revenue

Many organizations will claim to have an architect who creates architecture. Others will attempt to buy a nicely packaged architecture from one of the Big Five consulting firms without having a clue as to what they are getting. If your architecture does not address the following principles, you may be doing more harm than good:

  • Data are separated from logic (business functions).
  • The principles of modularity are observed by ensuring that each component within the enterprise architecture performs only one or two discrete tasks.
  • Functions are separated into differentiated tasks that are generic and self-contained.
  • The architecture is self-documenting. If it isn't, something is wrong.
  • All data and artifacts that are generated by an organization are managed and maintained by the same organization.
  • The architecture is technically feasible and can be implemented at a reasonable cost within a reasonable time frame.
  • The architecture is traceable from business requirement to technology implementation.
  • Logical architecture is separated from physical architecture.

The term architect was derived from the building trade. The building of a corporation's nervous system is directly comparable to building a house. One may say, "I have no clue about how to build a $50 million dollar skyscraper, let alone a $50,000 house." Yet the response to both tasks is simple: They are accomplished by creating blueprints.

Blueprints show how a house will be constructed. They provide multiple views, each expressing its own level of detail. One view of the house may include all the electrical circuits that are of extreme value to an electrician. Likewise, the plumber will need a blueprint to show where all the pipes and water should go. Enterprise architecture diagrams the blueprints for all of the people within an organization so they know how to build an agile enterprise. The enterprise architecture blueprint is meant to provide sufficient detail to allow the idea to become a reality when put in the hands of skilled professionals, much as a house blueprint does.

We do not mean to imply that building a skyscraper is as easy as building a house. A decade ago, Garlan stated, "As the size and complexity of software systems increases, the design problem goes beyond the algorithms and data structures of the computation: designing and specifying the overall system structure emerges as a new kind of problem. . . . This is the software architecture level of design." Garlan 1992.

Enterprise architecture within this context seeks to solve for intellectual manageability. Architecture of large projects and their complexity arise from broad scope, massive size, novelties of the minute, currently deployed technologies, and other factors. The goal of enterprise architecture in this situation is to provide a manner to hide unnecessary detail, simplify difficult-to-understand concepts, and break down the problem into better-understood components (decomposition).

Complexity also arises within organizations due to processes used in building the system, the number of people who are involved with construction, the introduction of the possibility of outsourcing and geographically dispersed teams, and the organizational funding model. Ideally, enterprise architecture can assist, but not eliminate, the management of the process by providing clearer separation of concerns, enhancing communications, and making dependencies more manageable.

Building enterprise architecture is difficult but not impossible, as long as one sticks to architectural principles. The architectural blueprint defines what should be built, not how or why. Project plans document the how, and their creation is best left to individuals who have studied project management. The why is best left to one's business customer, as all architecture should be business-driven.

A word of advice: A good architecture provides agility but also provides constraints. A highly successful architecture will remove points of decision from those who are traditionally accustomed to having a free-for-all, making decisions impulsively or reacting to the opinions of those who are uninformed. Good architects will see things that make their heads hurt, but their aspirin is in knowing that their hard work and persistence will result in the reduction of future problems. Helping others see the value of enterprise architecture is crucial, as it brings benefit to the enterprise even if decisions have local consequences.

The idea for this book came about during a lunchtime conversation between two of its authors. They were reminiscing about why the computer field was the only field in which one could become a manager, director, or even vice president without any computing experience. During this lunchtime conversation, we compared the computer field to such other professional fields as accounting, the practice and enforcement of law, and medicine.

Imagine that the town you live in is looking to hire a new police chief. Can you have confidence in the chief if he has never been a police officer? Furthermore, what if the prospective chief does not know how to use a gun and has no knowledge of proper investigation procedures? Extend this concept by envisioning a former McDonald's manager applying to be a partner at an accounting or law firm simply because he is a leader. The partners in the legal and accounting fields are leaders, but they also retain current knowledge of their professions and can argue a case or balance one's books. With relevant experience, the prospective police chief is a leader, too, and most likely remembers how to write a parking ticket and perform other cop-on-the-street duties.

Getting to the root of this problem cannot be done quickly. Unlike other fields, in the computer field you can have the title of architect but not necessarily know your job. The information technology field is constantly evolving and ever-changing. For the motivated, it requires long hours reading numerous books by the thought leaders of the industry. Even for the most diligent, the goal of achieving knowledge and enlightenment may never be fulfilled.

Many businesses are faced with such challenging problems as technology changing rapidly, employees with limited skill sets, smaller budgets, and less tolerance for failure. The only way one can be successful in this new order is to learn a new strategy. Today's businesspeople no longer have the opportunity to learn from their failures.

This book presents several provocative alternatives and serves as a leader, teacher, and guide to help you manage the chaos. It will challenge both the conventional and the contrarian's wisdom. This book is written by some of the brightest information technology thought leaders with the purpose of helping you create an agile enterprise using techniques learned on the battlefield of life.Come to success.The goal of this book is to share insight gathered by industry thought leaders in an easy-to-read and practical style. This book contains many leading-edge examples that illustrate how enterprise architecture can be applied to existing business and technology issues to help one focus on how to think concretely about enterprise architecture while providing solutions to today's problems. The following topics are covered within this book:

  • Systems architecture
  • Software architecture
  • Service-oriented architecture
  • Product-line practice
  • Methodology
  • Enterprise unified process
  • Agile architecture
  • Agile modeling
  • Presentation tier architecture
  • User experience and usability
  • Data architecture
  • Thought leadership

Authors and readers alike have their own religion when it comes to the best way a given topic should be explained. The examples contained within this book will not be blow-by-blow descriptions of the subjects. There are books better suited for this goal. We shall strictly focus on content that provides an additional value-added experience.

The author team also believes this book is not one to curl up with and read from cover to cover. The topics contained within this book mandate further study and even implementation before they can be fully appreciated.Audience

This book is suitable for all information technology professionals who have the passion and discipline to study technology to the level required for successful implementation. Ideally, the reader of this book should be a project manager, senior developer, software architect, or enterprise architect employed by a Fortune 1000 organization or by a consulting firm that serves these enterprises. This book is also suitable for such information technology executives as chief information officers (CIO), chief technology officers (CTO), and others within the IT technology management chain.

Since architect is not a title one is granted based merely on the number of years on the job, this author team has intentionally avoided making any references to years of experience in the profession. We assume that the reader has basic familiarity with emerging technologies and their use in solving existing problems. We provide references in Appendix E hat the readers may refer to if they are interested in drilling deeper into any particular topic.The advice, diagrams, and recommendations contained within this book may be used however you desire, with the sole exception that you may not claim you were the author. The publisher, authors, and their respective employers do not provide any form of warranty or guarantee this book's usefulness for any particular purpose.

Developing an enterprise architecture is a difficult task. It requires refinement of overlapping and conflicting requirements; invention of good abstractions from those requirements; formation of an efficient, cost-effective implementation; and ingenious solutions to isolated coding and abstraction evils. Additionally, enterprise architects must manage all this work up to a successful finish, all at the lowest possible cost in time and money. The only way this can be truly accomplished is by remaining agile.

In an agile approach, architects assume responsibilities beyond modeling and conceptual design. They must minimally serve as technical advisors to project managers. This is analogous to industrial engineers and their relationships to architects in the construction fields.

Many of the thoughts presented will assume an agile approach to explaining the solutions to the problems presented. An understanding of agile methods for software development will help readers become more successful in implementing practical enterprise architecture.

Read More Show Less

Table of Contents

Acknowledgments.

Foreword.

Preface.

1. Systems Architecture.

Canaxia Brings an Architect on Board. Network Protocols. Conclusion.

2. Software Architecture.

What Is Software Architecture? The Role of a Software Architect. Why We Need Software Architecture. The System Stakeholders. Creating a Software Architecture: An Example. Architecture Description Languages and UML. Quality Attributes. Architectural Viewpoints. Architectural Styles, Patterns, and Metaphors. Conclusion.

3. Service-Oriented Architecture.

Benefits of an SOA. Characteristics of an SOA. Web Services. Services at Canaxia. SOA Issues. SOA Management. SOA Best Practices. SOA Antipatterns. Conclusion.

4. Software Product Lines.

Product Lines at Canaxia. History of Product Lines. What Is a Software Product Line? Product Line Benefits. Product Line Aspects. Conclusion.

5. Methodology Overview.

The Software Development Life Cycle. Extreme Programming. SEI/CMM. The Zachman Framework. Model-Driven Architecture. Rational Unified Process. Using These Methodologies. Conclusion.

6. Enterprise Unified Process.

The Enterprise-Unified Process. The Production Phase. The Retirement Phase. The Operations and Support Discipline. The Enterprise Management Discipline. Why Adopt the EUP? Conclusion.

7. Agile Architecture.

Agility in a Nutshell. Potential Problems with Traditional Approaches to Enterprise Architecture. An Agile Approach to Architecture. What Should Agile Architecture Efforts Produce? Agile Architecture at Canaxia. Introducing an Agile Approach into Your Organization. Are Other Architecture Approaches Agile? Potential Problems with an Agile Approach. Conclusion.

8. Agile Modeling.

The Goals of Agile Modeling. Agile Models. Agile Documents. Conclusion.

9. Presentation Tier Architecture.

Key Presentation Tier Components. General Design Recommendations. Design Guidelines for Interface Components. Conclusion.

10. Usability and User Experience.

Understanding Usability. User Experience Components. Usability and User Experience Design Process. Usability Techniques. Sharing the Usability Test Reports. Out-of-the-Box Experience. Conclusion.

11. Data Architecture.

The Business Problem. Baseline Data Architecture. Frameworks. Metadata. Advanced Metadata Architecture. Data Security. Agile Database Techniques. Conclusion.

12. Thought Leadership.

Organizational Matrix. Outsourcing and Core Competencies. Strong Technical Leadership. Architects Stand the Test of Time. The Savage Pursuit of Best Practices. The Agile CIO. The Mysteries of Open Source. Consultant 101. Why I Should Be a CIO. The Next Minute. Conclusion.

Appendix A.

Appendix B.

Appendix C.

Appendix D.

Appendix E.

Appendix F.

Appendix G.

About the Authors.

Index.

Read More Show Less

Preface

Preface

In today's business climate, the rules of competition have changed. Organizations are forced to eliminate the process of reinventing the wheel each time a new business problem arises that forces the enhancement of an existing system or implementation of a new one. Enterprise architecture is the practice that allows organizations to build foundations they need to survive and adapt to present and future business challenges. Sound enterprise architecture supports the ability to stay agile, provides for increased return on investment, and creates a framework for making future technology decisions.

Enterprise architecture identifies the main components of an organization and how components in the organization's nervous system function together to achieve defined business objectives. These components include personnel, business processes, technology, financial information and other resources. If decisions about components and their interrelationships are uncoordinated, minimally effort and resources will be duplicated; performance and management problems will arise and will result in the loss of agility. Enterprise architecture done correctly will ensure the choice of appropriate components and will specify how each component will operate together in a fluid manner that increases organizational efficiencies.

Enterprise architecture is one of the most challenging roles in information technology today. Many aspects of the role are technical while much more of it is about interaction. Many people who have this position have significant responsibility but do not have authority or control. Enterprise architecture as an area of study allows one to focus on interesting, complex problems, to advance on the corporate ladder, and to maintain technical competencies while making a colossal difference to the enterprise.

Enterprise architecture requires skill sets not normally taught in university curriculum or acquired on the job. Even good architectures are rarely accepted without formidable challenges. The successful architect has to overcome any aversion to politics and become the evangelist of architecture in the eyes of its various stakeholders. Architects cannot simply buy into any vision that is articulated. Any involvement in the implementation of enterprise architecture requires one to understand it. The most successful architecture will have an architect that can describe the motivation behind architectural choices. Likewise, a successful architecture has an architect who leads the architecture team, the development team, the technical direction of the enterprise, and sometimes the organization itself. The primary focus of this book is to be a guide and trusted advisor to those who want to be successful in this role.A wise enterprise architect once worked for a very well-respected organization (name intentionally withheld). He was passionately engaged in a conversation with a senior executive about what direction the organization should take with its information systems. His recommendations fell on deaf ears until he asked the executive three very simple questions:

  • How can we have a viable customer relationship management strategy when we do not even know where all of our customer's data reside?
  • How does our technology spending equate to enabling our strategic business goals?
  • Does our organization have an operational process model?

As you can surmise, the answers to these questions were not known. Many executives in information technology are not knowledgeable about what it takes to guide the architecture in the direction that results in the biggest bang for the buck. Sadly, many executives have lost control of the ship they steer, which has resulted in bloated infrastructures and conclusions being made on whims rather than on sound principle-based judgment and experience.In many organizations, the annual budget cycle starts with clueless, disruptive questions such as "How many servers do we have?" or "Let's get the new Intel 3333 GHz machines as desktops." None of these statements is appropriate for a discussion about enterprise architecture. A good architecture addresses the following:

  • The organization's business and information needs
  • Leverage of the synergistic relationship between return on investment (ROI) and total cost of ownership (TCO)
  • The ability to support migration from the current state (as-is)
  • The ability to support easy migration to the organization's desired future state
  • Ways to support the business objectives of reducing costs, improving operational service, and increasing revenue

Many organizations will claim to have an architect who creates architecture. Others will attempt to buy a nicely packaged architecture from one of the Big Five consulting firms without having a clue as to what they are getting. If your architecture does not address the following principles, you may be doing more harm than good:

  • Data are separated from logic (business functions).
  • The principles of modularity are observed by ensuring that each component within the enterprise architecture performs only one or two discrete tasks.
  • Functions are separated into differentiated tasks that are generic and self-contained.
  • The architecture is self-documenting. If it isn't, something is wrong.
  • All data and artifacts that are generated by an organization are managed and maintained by the same organization.
  • The architecture is technically feasible and can be implemented at a reasonable cost within a reasonable time frame.
  • The architecture is traceable from business requirement to technology implementation.
  • Logical architecture is separated from physical architecture.

The term architect was derived from the building trade. The building of a corporation's nervous system is directly comparable to building a house. One may say, "I have no clue about how to build a $50 million dollar skyscraper, let alone a $50,000 house." Yet the response to both tasks is simple: They are accomplished by creating blueprints.

Blueprints show how a house will be constructed. They provide multiple views, each expressing its own level of detail. One view of the house may include all the electrical circuits that are of extreme value to an electrician. Likewise, the plumber will need a blueprint to show where all the pipes and water should go. Enterprise architecture diagrams the blueprints for all of the people within an organization so they know how to build an agile enterprise. The enterprise architecture blueprint is meant to provide sufficient detail to allow the idea to become a reality when put in the hands of skilled professionals, much as a house blueprint does.

We do not mean to imply that building a skyscraper is as easy as building a house. A decade ago, Garlan stated, "As the size and complexity of software systems increases, the design problem goes beyond the algorithms and data structures of the computation: designing and specifying the overall system structure emerges as a new kind of problem. . . . This is the software architecture level of design." Garlan 1992.

Enterprise architecture within this context seeks to solve for intellectual manageability. Architecture of large projects and their complexity arise from broad scope, massive size, novelties of the minute, currently deployed technologies, and other factors. The goal of enterprise architecture in this situation is to provide a manner to hide unnecessary detail, simplify difficult-to-understand concepts, and break down the problem into better-understood components (decomposition).

Complexity also arises within organizations due to processes used in building the system, the number of people who are involved with construction, the introduction of the possibility of outsourcing and geographically dispersed teams, and the organizational funding model. Ideally, enterprise architecture can assist, but not eliminate, the management of the process by providing clearer separation of concerns, enhancing communications, and making dependencies more manageable.

Building enterprise architecture is difficult but not impossible, as long as one sticks to architectural principles. The architectural blueprint defines what should be built, not how or why. Project plans document the how, and their creation is best left to individuals who have studied project management. The why is best left to one's business customer, as all architecture should be business-driven.

A word of advice: A good architecture provides agility but also provides constraints. A highly successful architecture will remove points of decision from those who are traditionally accustomed to having a free-for-all, making decisions impulsively or reacting to the opinions of those who are uninformed. Good architects will see things that make their heads hurt, but their aspirin is in knowing that their hard work and persistence will result in the reduction of future problems. Helping others see the value of enterprise architecture is crucial, as it brings benefit to the enterprise even if decisions have local consequences.

The idea for this book came about during a lunchtime conversation between two of its authors. They were reminiscing about why the computer field was the only field in which one could become a manager, director, or even vice president without any computing experience. During this lunchtime conversation, we compared the computer field to such other professional fields as accounting, the practice and enforcement of law, and medicine.

Imagine that the town you live in is looking to hire a new police chief. Can you have confidence in the chief if he has never been a police officer? Furthermore, what if the prospective chief does not know how to use a gun and has no knowledge of proper investigation procedures? Extend this concept by envisioning a former McDonald's manager applying to be a partner at an accounting or law firm simply because he is a leader. The partners in the legal and accounting fields are leaders, but they also retain current knowledge of their professions and can argue a case or balance one's books. With relevant experience, the prospective police chief is a leader, too, and most likely remembers how to write a parking ticket and perform other cop-on-the-street duties.

Getting to the root of this problem cannot be done quickly. Unlike other fields, in the computer field you can have the title of architect but not necessarily know your job. The information technology field is constantly evolving and ever-changing. For the motivated, it requires long hours reading numerous books by the thought leaders of the industry. Even for the most diligent, the goal of achieving knowledge and enlightenment may never be fulfilled.

Many businesses are faced with such challenging problems as technology changing rapidly, employees with limited skill sets, smaller budgets, and less tolerance for failure. The only way one can be successful in this new order is to learn a new strategy. Today's businesspeople no longer have the opportunity to learn from their failures.

This book presents several provocative alternatives and serves as a leader, teacher, and guide to help you manage the chaos. It will challenge both the conventional and the contrarian's wisdom. This book is written by some of the brightest information technology thought leaders with the purpose of helping you create an agile enterprise using techniques learned on the battlefield of life.Come to success.

The goal of this book is to share insight gathered by industry thought leaders in an easy-to-read and practical style. This book contains many leading-edge examples that illustrate how enterprise architecture can be applied to existing business and technology issues to help one focus on how to think concretely about enterprise architecture while providing solutions to today's problems. The following topics are covered within this book:

  • Systems architecture
  • Software architecture
  • Service-oriented architecture
  • Product-line practice
  • Methodology
  • Enterprise unified process
  • Agile architecture
  • Agile modeling
  • Presentation tier architecture
  • User experience and usability
  • Data architecture
  • Thought leadership

Authors and readers alike have their own religion when it comes to the best way a given topic should be explained. The examples contained within this book will not be blow-by-blow descriptions of the subjects. There are books better suited for this goal. We shall strictly focus on content that provides an additional value-added experience.

The author team also believes this book is not one to curl up with and read from cover to cover. The topics contained within this book mandate further study and even implementation before they can be fully appreciated.

Audience

This book is suitable for all information technology professionals who have the passion and discipline to study technology to the level required for successful implementation. Ideally, the reader of this book should be a project manager, senior developer, software architect, or enterprise architect employed by a Fortune 1000 organization or by a consulting firm that serves these enterprises. This book is also suitable for such information technology executives as chief information officers (CIO), chief technology officers (CTO), and others within the IT technology management chain.

Since architect is not a title one is granted based merely on the number of years on the job, this author team has intentionally avoided making any references to years of experience in the profession. We assume that the reader has basic familiarity with emerging technologies and their use in solving existing problems. We provide references in Appendix E hat the readers may refer to if they are interested in drilling deeper into any particular topic.The advice, diagrams, and recommendations contained within this book may be used however you desire, with the sole exception that you may not claim you were the author. The publisher, authors, and their respective employers do not provide any form of warranty or guarantee this book's usefulness for any particular purpose.

Developing an enterprise architecture is a difficult task. It requires refinement of overlapping and conflicting requirements; invention of good abstractions from those requirements; formation of an efficient, cost-effective implementation; and ingenious solutions to isolated coding and abstraction evils. Additionally, enterprise architects must manage all this work up to a successful finish, all at the lowest possible cost in time and money. The only way this can be truly accomplished is by remaining agile.

In an agile approach, architects assume responsibilities beyond modeling and conceptual design. They must minimally serve as technical advisors to project managers. This is analogous to industrial engineers and their relationships to architects in the construction fields.

Many of the thoughts presented will assume an agile approach to explaining the solutions to the problems presented. An understanding of agile methods for software development will help readers become more successful in implementing practical enterprise architecture.

Read More Show Less

Introduction

Preface

In today's business climate, the rules of competition have changed. Organizations are forced to eliminate the process of reinventing the wheel each time a new business problem arises that forces the enhancement of an existing system or implementation of a new one. Enterprise architecture is the practice that allows organizations to build foundations they need to survive and adapt to present and future business challenges. Sound enterprise architecture supports the ability to stay agile, provides for increased return on investment, and creates a framework for making future technology decisions.

Enterprise architecture identifies the main components of an organization and how components in the organization's nervous system function together to achieve defined business objectives. These components include personnel, business processes, technology, financial information and other resources. If decisions about components and their interrelationships are uncoordinated, minimally effort and resources will be duplicated; performance and management problems will arise and will result in the loss of agility. Enterprise architecture done correctly will ensure the choice of appropriate components and will specify how each component will operate together in a fluid manner that increases organizational efficiencies.

Enterprise architecture is one of the most challenging roles in information technology today. Many aspects of the role are technical while much more of it is about interaction. Many people who have this position have significant responsibility but do not have authority or control. Enterprise architecture as an area of study allows one to focus oninteresting, complex problems, to advance on the corporate ladder, and to maintain technical competencies while making a colossal difference to the enterprise.

Enterprise architecture requires skill sets not normally taught in university curriculum or acquired on the job. Even good architectures are rarely accepted without formidable challenges. The successful architect has to overcome any aversion to politics and become the evangelist of architecture in the eyes of its various stakeholders. Architects cannot simply buy into any vision that is articulated. Any involvement in the implementation of enterprise architecture requires one to understand it. The most successful architecture will have an architect that can describe the motivation behind architectural choices. Likewise, a successful architecture has an architect who leads the architecture team, the development team, the technical direction of the enterprise, and sometimes the organization itself. The primary focus of this book is to be a guide and trusted advisor to those who want to be successful in this role. A wise enterprise architect once worked for a very well-respected organization (name intentionally withheld). He was passionately engaged in a conversation with a senior executive about what direction the organization should take with its information systems. His recommendations fell on deaf ears until he asked the executive three very simple questions:

  • How can we have a viable customer relationship management strategy when we do not even know where all of our customer's data reside?
  • How does our technology spending equate to enabling our strategic business goals?
  • Does our organization have a operational process model?

As you can surmise, the answers to these questions were not known. Many executives in information technology are not knowledgeable about what it takes to guide the architecture in the direction that results in the biggest bang for the buck. Sadly, many executives have lost control of the ship they steer, which has resulted in bloated infrastructures and conclusions being made on whims rather than on sound principle-based judgment and experience. In many organizations, the annual budget cycle starts with clueless, disruptive questions such as "How many servers do we have?" or "Let's get the new Intel 3333 GHz machines as desktops." None of these statements is appropriate for a discussion about enterprise architecture. A good architecture addresses the following:

  • The organization's business and information needs
  • Leverage of the synergistic relationship between return on investment (ROI) and total cost of ownership (TCO)
  • The ability to support migration from the current state (as-is)
  • The ability to support easy migration to the organization's desired future state
  • Ways to support the business objectives of reducing costs, improving operational service, and increasing revenue

Many organizations will claim to have an architect who creates architecture. Others will attempt to buy a nicely packaged architecture from one of the Big Five consulting firms without having a clue as to what they are getting. If your architecture does not address the following principles, you may be doing more harm than good:

  • Data are separated from logic (business functions).
  • The observed by ensuring that each component within the enterprise architecture performs only one or two discrete tasks.
  • Functions are separated into differentiated tasks that are generic and self-contained.
  • The architecture is self-documenting. If it isn't, something is wrong.
  • All data and artifacts that are generated by an organization are managed and maintained by the same organization.
  • The architecture is technically feasible and can be implemented at a reasonable cost within a reasonable time frame.
  • The architecture is traceable from business requirement to technology implementation.
  • Logical architecture is separated from physical architecture.

The term architect was derived from the building trade. The building of a corporation's nervous system is directly comparable to building a house. One may say, "I have no clue about how to build a $50 million dollar skyscraper, let alone a $50,000 house." Yet the response to both tasks is simple: They are accomplished by creating blueprints.

Blueprints show how a house will be constructed. They provide multiple views, each expressing its own level of detail. One view of the house may include all the electrical circuits that are of extreme value to an electrician. Likewise, the plumber will need a blueprint to show where all the pipes and water should go. Enterprise architecture diagrams the blueprints for all of the people within an organization so they know how to build an agile enterprise. The enterprise architecture blueprint is meant to provide sufficient detail to allow the idea to become a reality when put in the hands of skilled professionals, much as a house bluepri does.

We do not mean to imply that building a skyscraper is as easy as building a house. A decade ago, Garlan stated, "As the size and complexity of software systems increases, the design problem goes beyond the algorithms and data structures of the computation: designing and specifying the overall system structure emerges as a new kind of problem. . . . This is the software architecture level of design." Garlan 1992.

Enterprise architecture within this context seeks to solve for intellectual manageability. Architecture of large projects and their complexity arise from broad scope, massive size, novelties of the minute, currently deployed technologies, and other factors. The goal of enterprise architecture in this situation is to provide a manner to hide unnecessary detail, simplify difficult-to-understand concepts, and break down the problem into better-understood components (decomposition).

Complexity also arises within organizations due to processes used in building the system, the number of people who are involved with construction, the introduction of the possibility of outsourcing and geographically dispersed teams, and the organizational funding model. Ideally, enterprise architecture can assist, but not eliminate, the management of the process by providing clearer separation of concerns, enhancing communications, and making dependencies more manageable.

Building enterprise architecture is difficult but not impossible, as long as one sticks to architectural principles. The architectural blueprint defines what should be built, not how or why. Project plans document the how, and their creation is best left to individuals who have studied project management. The why is best left to one's business customer, as all architecture should be business-driven.

A word of advice: A good architecture provides agility but also provides constraints. A highly successful architecture will remove points of decision from those who are traditionally accustomed to having a free-for-all, making decisions impulsively or reacting to the opinions of those who are uninformed. Good architects will see things that make their heads hurt, but their aspirin is in knowing that their hard work and persistence will result in the reduction of future problems. Helping others see the value of enterprise architecture is crucial, as it brings benefit to the enterprise even if decisions have local consequences.

The idea for this book came about during a lunchtime conversation between two of its authors. They were reminiscing about why the computer field was the only field in which one could become a manager, director, or even vice president without any computing experience. During this lunchtime conversation, we compared the computer field to such other professional fields as accounting, the practice and enforcement of law, and medicine.

Imagine that the town you live in is looking to hire a new police chief. Can you have confidence in the chief if he has never been a police officer? Furthermore, what if the prospective chief does not know how to use a gun and has no knowledge of proper investigation procedures? Extend this concept by envisioning a former McDonald's manager applying to be a partner at an accounting or law firm simply because he is a leader. The partners in the legal and accounting fields are leaders, but they also retain current knowledge of their professions and can argue a case or balance one's books. With relevant experience, the prospective police chief is a leader, too, and most likely remembers how to write a parking ticket and perform other cop-on-the-street duties.

Getting to the root of this problem cannot be done quickly. Unlike other fields, in the computer field you can have the title of architect but not necessarily know your job. The information technology field is constantly evolving and ever-changing. For the motivated, it requires long hours reading numerous books by the thought leaders of the industry. Even for the most diligent, the goal of achieving knowledge and enlightenment may never be fulfilled.

Many businesses are faced with such challenging problems as technology changing rapidly, employees with limited skill sets, smaller budgets, and less tolerance for failure. The only way one can be successful in this new order is to learn a new strategy. Today's businesspeople no longer have the opportunity to learn from their failures.

This book presents several provocative alternatives and serves as a leader, teacher, and guide to help you manage the chaos. It will challenge both the conventional and the contrarian's wisdom. This book is written by some of the brightest information technology thought leaders with the purpose of helping you create an agile enterprise using techniques learned on the battlefield of life. Come to success.

The goal of this book is to share insight gathered by industry thought leaders in an easy-to-read and practical style. This book contains many leading-edge examples that illustrate how enterprise architecture can be applied to existing business and technology issues to help one focus on how to think concretely about enterprise architecture while providing solutions to today's problems. The following topics are covered within this book:
  • Systems architecture
  • Software architecture
  • Service-oriented architecture
  • Product-line practice
  • Methodology
  • Enterprise unified process
  • Agile architecture
  • Agile modeling
  • Presentation tier architecture
  • User experience and usability
  • Data architecture
  • Thought leadership

Authors and readers alike have their own religion when it comes to the best way a given topic should be explained. The examples contained within this book will not be blow-by-blow descriptions of the subjects. There are books better suited for this goal. We shall strictly focus on content that provides an additional value-added experience.

The author team also believes this book is not one to curl up with and read from cover to cover. The topics contained within this book mandate further study and even implementation before they can be fully appreciated.

Audience

This book is suitable for all information technology professionals who have the passion and discipline to study technology to the level required for successful implementation. Ideally, the reader of this book should be a project manager, senior developer, software architect, or enterprise architect employed by a Fortune 1000 organization or by a consulting firm that serves these enterprises. This book is also suitable for such information technology executives as chief information officers (CIO), chief technology officers (CTO), and others within the IT technology mana architect is not a title one is granted based merely on the number of years on the job, this author team has intentionally avoided making any references to years of experience in the profession. We assume that the reader has basic familiarity with emerging technologies and their use in solving existing problems. We provide references in Appendix E hat the readers may refer to if they are interested in drilling deeper into any particular topic. The advice, diagrams, and recommendations contained within this book may be used however you desire, with the sole exception that you may not claim you were the author. The publisher, authors, and their respective employers do not provide any form of warranty or guarantee this book's usefulness for any particular purpose.

Developing an enterprise architecture is a difficult task. It requires refinement of overlapping and conflicting requirements; invention of good abstractions from those requirements; formation of an efficient, cost-effective implementation; and ingenious solutions to isolated coding and abstraction evils. Additionally, enterprise architects must manage all this work up to a successful finish, all at the lowest possible cost in time and money. The only way this can be truly accomplished is by remaining agile.

In an agile approach, architects assume responsibilities beyond modeling and conceptual design. They must minimally serve as technical advisors to project managers. This is analogous to industrial engineers and their relationships to architects in the construction fields.

Many of the thoughts presented will assume an agile approach to explaining the solutions to the problems presented. An understanding of agile methods for software development will help readers become more successful in implementing practical enterprise architecture.

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)