Home > Store

Software Fortresses: Modeling Enterprise Architectures

Register your product to gain access to bonus material or receive a coupon.

Software Fortresses: Modeling Enterprise Architectures

Book

  • Sorry, this book is no longer in print.
Not for Sale

Description

  • Copyright 2003
  • Edition: 1st
  • Book
  • ISBN-10: 0-321-16608-6
  • ISBN-13: 978-0-321-16608-1

This book introduces a new approach for modeling large enterprise systems: the software fortress model. In the software fortress model, an enterprise architecture is viewed as a series of self-contained, mutually suspicious, marginally cooperating software fortresses interacting with each other through carefully crafted and meticulously managed treaty relationships.

The software fortress model is an intuitive, simple, expressive approach that maps readily to existing technologies such as .NET and Java 2 Enterprise Edition (J2EE). This book is designed to meet an immediate need to define, clarify, and explain the basics of this new modeling methodology for large enterprise software architectures.

Software Fortresses is your essential roadmap to all aspects of software fortresses.

Key topics include:

  • The fundamental concepts and terminology of software fortresses
  • Documentation techniques, including Fortress Ally Responsibility Cards (based on Class Responsibility Cards) and Sequence Ally Diagrams (based on UML's Class Sequence Diagrams)
  • The proper use of drawbridges to provide fortress interoperability
  • The innovative software fortress model for enterprise security
  • Correct design approaches to fortress walls, which keep intruders out, and to guards, which let allies in.
  • The role of loosely coupled and tightly coupled transactions in a software fortress architecture
  • Design and technology issues associated with the six major software fortress types
  • This book is a must-read for all enterprise software professionals, whether you are a manager seeking to rein in run-away enterprise system complexity, an architect seeking to design interoperable, scalable, and highly secure systems, a consultant expected to give advice on how .NET and J2EE fit into the enterprise space, an implementer wanting to understand how your system relates to a larger enterprise architecture, or a business analyst needing to know that your system requirements will be translated into a successful software implementation.



    0321166086B12202002

    Sample Content

    Online Sample Chapter

    Guards and Walls of Software Fortresses

    Downloadable Sample Chapter

    Click below for Sample Chapter(s) related to this title:
    Sample Chapter 7

    Table of Contents



    Preface.


    The Software Fortress Model.


    Who Cares about Software Fortresses?


    The Goals of This Book.


    Who Should Read This Book.


    The History of the Software Fortress Model.


    The Organization of This Book.


    Acknowledgments.


    About the Author.


    1. Introduction.

    Definitions.

    Software Fortress Organization.

    Typical Technologies.

    The Fortress as a Trust Boundary.

    The Main Fortress Types.

    Treaty Relationships.

    The Fortress as a Unit of Interoperability.

    Objects, Components, and Fortresses.

    Summary.



    2. Diagramming Software Fortresses.

    Basic Software Fortress Diagram.

    Fortress-Ally Diagram.

    Treaty-Ally Diagram.

    Sequence-Ally Diagram.

    Fortress-Ally-Responsibility Cards.

    Treaty-Ally-Responsibility Cards.

    Fortress Overview Document.

    Treaty Overview Document.

    Summary.



    3. Transactions.

    Transactionally Aware Resources.

    Tightly Coupled Single-Resource Transactions.

    Multiple-Resource Transactions.

    Loosely Coupled Multiple-Resource Transactions.

    Tightly Coupled Multiple-Resource Transactions.

    The Distributed Transaction Coordinator.

    Summary.



    4. Drawbridges.

    Drawbridge Overview.

    Summary.



    5. Synchronous Drawbridges.

    Components.

    Homogeneous Synchronous Drawbridges.

    Heterogeneous Synchronous Drawbridges.

    Summary.



    6. Asynchronous Drawbridges.

    Message Queues.

    Implementation of Asynchronous Drawbridges.

    Persistence and Transactions in Queues.

    Heterogeneous Asynchronous Drawbridges.

    Homogeneous Asynchronous Drawbridges.

    Advantages of Asynchronous Drawbridges

    Nonblocking Workflow.

    Pseudoreliability.

    Workload Averaging.

    Poor-Man's Clustering.

    Performance Problems of Asynchronous Drawbridges.

    Summary.



    7. Guards and Walls.

    Fortification.

    Validation.

    Auditing.

    Authentication.

    Privacy.

    Integrity.

    Nonrepudiation.

    Authorization.

    Summary.



    8. Treaties.

    A Treaty between Two Fortresses.

    Treaty Considerations.

    Summary.



    9. General Fortress Issues.

    Scalability.

    Reliability.

    Integrity.

    Summary.



    10. Internet Fortresses.

    Presentation Fortresses.

    J2EE versus the .NET Approach.

    Scalability.

    Security.

    Reliability.

    Integrity.

    Web Service Fortresses.

    J2EE versus the .NET Approach.

    Technology Overview.

    SOAP Problems.

    Scalability.

    Security.

    Reliability.

    Integrity.

    Summary.



    11. Business Application Fortresses.

    Foundation: Components and COMWare.

    State Management.

    Transaction Boundary Management.

    State Management Revisited.

    Leveraging Clusters.

    .NET versus the J2EE Approach.

    Language.

    Platform Support.

    Cost.

    Summary.



    12. Legacy, Service, and Treaty Management Fortresses.

    Legacy Fortresses.

    Service Fortresses

    Broadcast Service Fortresses.

    Data-Sharing Fortresses.

    Security Fortresses.

    Loosely Coupled Transaction Management Service Fortresses.

    Treaty Management Fortresses.

    Summary.



    13. Software Fortress Design Review.

    Group One: Enterprise Overview Questions.

    Question 1: Do we need a software fortress architecture?

    Question 2: Do we all have the same understanding of the software fortress methodology?

    Question 3: Have the requirements for each fortress been clearly articulated?

    Question 4: Have our fortresses been partitioned with organizational boundaries in mind?

    Question 5: Are our fortresses organized around natural trust boundaries?

    Question 6: Have we really made enterprise-level decisions at the enterprise level and fortress-level decisions at the fortress level?

    Question 7: Have we confused objects, components, and fortresses?

    Question 8: Have we identified all of the security issues?

    Group Two: Enterprise Architecture Questions.

    Question 9: Do we have the right number of fortresses?

    Question 10: Are all drawbridge requests idempotent?

    Question 11: Are all drawbridge requests for substantial work?

    Question 12: Do we have any tightly coupled transactions across fortresses?

    Question 13: Are all drawbridges heterogeneous asynchronous?

    Question 14: Does all interfortress communication pass through drawbridges?

    Question 15: Have we considered all of the risk factors inherent in our presentation and Web service fortresses?

    Group Three: Fortress Architecture Questions.

    Question 16: Are we considering fortress-appropriate technologies?

    Question 17: If we must use a synchronous drawbridge, do we have an asynchronous back end?

    Question 18: Are we using more than one technology base within a single fortress?

    Question 19: Have we designed a scale-out architecture?

    Question 20: Have we designed a fortress architecture that can leverage loosely coupled clusters for reliability?

    Question 21: Have we designed adequate security for each of our guards?

    Question 22: Have we built effective walls around the fortress?

    Question 23: Are we using only homogeneous synchronous communications within the fortress?

    Question 24: Do all of our outgoing communications pass through envoys?

    Question 25: Is all of our data being stored in the data strongbox?

    Summary.



    14. Case Study.

    The Problem.

    First-Pass Design.

    Second-Pass Design.

    The ProcessOrder Drawbridges.

    The CheckInventory Drawbridges.

    Guards.

    Summary.



    15. Postlude.

    Ten Important Points about Software Fortresses.

    Ten Reasons to Adopt the Software Fortress Model.

    Ten Rules for Software Fortress Design.

    Ten Controversial Ideas within the Software Fortress Model.

    Ten Considerations for Evaluating J2EE versus .NET.

    Ten Observations on the State of the Software Industry.

    Where to Go Next.

    Final Words.



    Glossary.


    Index. 0321166086T01292003

    Preface

    Introduction

    You and I have never met. I have no idea what your business is. However, I do know what your enterprise architecture looks like. I can even show you the exact picture you use to describe your enterprise system. Take a look at Figure 0.1. Look familiar?

    It goes without saying that your enterprise is a perfect three-tier/N-tier software architecture. When describing your system, you wax poetic about your perky presentation tier, accepting HTTP requests from complacent clients and SOAP requests from congenial collaborators. You illuminate in minutiae how you manage your middle tier, running well behaved business logic cherubs, all gleefully sharing database connections and other valuable system resources. Behind all of this, your enterprise-wide database shouts encouragement from its sheltered back-end.

    See? I told you I know what your enterprise architecture looks like. I also know one other thing. I know you lie. You lie through your teeth.Your enterprise architecture looks nothing like Figure 0.1. Do you want to see the real picture of your enterprise architecture? Take a look at Figure 0.2. But first, sit down. It isn't pretty!

    In the real world, your clients are not meek, but malicious. Your middle tier is not well behaved, but made up of a disparate bunch of applications developed without regard for the needs of their stable mates. Your "database" is not an enterprise-wide anything but rather a series of disorganized data storage technologies that spend most of their time cringing from the unreasonable and often conflicting demands of the business logic.

    As architects, we have two choices. We can ignore this chaos or we can model it. When we model it, we have the opportunity to bring it under some degree of intellectual control.

    The Software Fortress Model

    This book introduces a new approach for modeling large enterprise systems. This approach is called the software fortress modeltm. The software fortress model treats enterprise systems as a series of self contained software fortresses. Each fortress makes its own choices as to software platform and data storage mechanisms and interacts with other fortresses through carefully crafted treaties. Without going into too much detail this early, a view of the same enterprise as shown in Figure 0.2, as seen from the software fortress model, looks like Figure 0.3. Don't worry at this point about what the cartoon figures mean, they will become familiar soon enough.

    The software fortress model pushes the simplification of the enterprise further and further. As we use the model to decompose the enterprise, Figure 0.3 becomes a series of collaborations, as shown in Figure 0.4.

    I will discuss what the software fortress model is throughout this book. For now, let's focus on why we need this model.

    The most important reason we need the software fortress model is to better understand how our systems interact within our overall enterprise architecture. Even without knowing the details of how the software fortress model works, you can quickly get the sense that Figures 0.3 and 0.4 are a lot more approachable than Figure 0.2.

    We already have many good techniques for modeling software systems. The most prevalent is the Universal Modeling Language (UML). However existing systems, including UML, focus on the issues involved with designing software systems. They have little to offer the enterprise architect in modeling how the various software systems that make up the enterprise architecture relate to each other. In other words, they are fine for modeling a sales system, an inventory system, or an accounts payable system. They are not useful in showing how a sales, inventory, and accounts payable system need to work together to coordinate a customer purchase.

    The software fortress model picks up where techniques like UML leave off. Or, to be more precise, UML picks up where the software fortress model leaves off. The software fortress model helps us describe and plan for the relationships between software systems. It is these relationships that ultimately define the enterprise architecture. UML and related technologies can then be used to document how those individual software systems are designed.

    Who Cares About Software Fortresses?

    The software fortress model has a lot to offer, especially for the high level manager, who is trying to understand the overall enterprise architecture, and for the enterprise architect, who is trying to explain it.

    For CTO types, the software fortress model offers these immediate payoffs:

  • The software fortress model aligns technology boundaries with organizational boundaries within the enterprise.
  • The software fortress model provides an intellectual framework for modeling and managing the technical complexity of enterprise systems.
  • The software fortress model cleanly separates issues that must be decided at the enterprise level from those that can be decided at the local level.
  • The software fortress model is technology independent and allows groups with different technology biases to discuss architectures using a common language.
  • Enterprise architects will appreciate these benefits of the software fortress model:
  • The software fortress model cleanly defines natural technical boundaries across which autonomous groups can agree to disagree.
  • The software fortress model provides a methodology for achieving interoperability between software systems.
  • The software fortress model provides a methodology for defining security at the enterprise level.
  • The software fortress model provides an intellectual framework within which one can meaningfully compare different technologies.
  • But it is not just CTOs and enterprise architects that will gain from the software fortress model, this model has the power to transform our entire industry. For the first time, our entire industry will share one lingua franca for discussing enterprise applications. Customers and clients will be able to readily communicate with programmers and architects; Java programmers will be able understand VisualBasic programmers; and architects from different business fields will be able to compare approaches to common problems.

    Over time, the software fortress model will influence the software platforms themselves. Tools will appear to directly support the model. Platforms will evolve as the model exposes underlying platform weaknesses. New technological approaches will be explored as the model helps us better understand the needs of the enterprise.

    Perhaps the most important contribution of the model is simplification. Simplification of security, simplification of interoperability, and simplification of collaboration. Simple systems are inherently better than complex systems. They are cheaper to build, they are more reliable, and they are more secure. We can all get behind that.

    The Goals Of This Book

    The software fortress model is still quite young, even by software standards. However I have already presented the main ideas that make up this model in person to over three thousand developers and conducted in-depth workshops with very high level enterprise architects from more than a dozen large companies. I have also introduced the ideas to the readership of the ObjectWatch Newsletter, which includes more than 20,000 readers including highly placed managers and architects at virtually all of the Fortune 500 companies.

    The response to the software fortress model, even in its relative state of immaturity, has been overwhelming. Almost everybody who is exposed to the software fortress model feels a strong sense of resonance, as if this model addresses a very basic requirement at their organization: the requirement to model and simplify their enterprise's complexity.

    This book is designed to meet an

    Index

    Click below to download the Index file related to this title:
    Index

    Updates

    Submit Errata

    More Information

    InformIT Promotional Mailings & Special Offers

    I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

    Overview


    Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

    This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

    Collection and Use of Information


    To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

    Questions and Inquiries

    For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

    Online Store

    For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

    Surveys

    Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

    Contests and Drawings

    Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

    Newsletters

    If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

    Service Announcements

    On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

    Customer Service

    We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

    Other Collection and Use of Information


    Application and System Logs

    Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

    Web Analytics

    Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

    Cookies and Related Technologies

    This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

    Do Not Track

    This site currently does not respond to Do Not Track signals.

    Security


    Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

    Children


    This site is not directed to children under the age of 13.

    Marketing


    Pearson may send or direct marketing communications to users, provided that

    • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
    • Such marketing is consistent with applicable law and Pearson's legal obligations.
    • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
    • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

    Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

    Correcting/Updating Personal Information


    If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

    Choice/Opt-out


    Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

    Sale of Personal Information


    Pearson does not rent or sell personal information in exchange for any payment of money.

    While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

    Supplemental Privacy Statement for California Residents


    California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

    Sharing and Disclosure


    Pearson may disclose personal information, as follows:

    • As required by law.
    • With the consent of the individual (or their parent, if the individual is a minor)
    • In response to a subpoena, court order or legal process, to the extent permitted or required by law
    • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
    • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
    • To investigate or address actual or suspected fraud or other illegal activities
    • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
    • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
    • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

    Links


    This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

    Requests and Contact


    Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

    Changes to this Privacy Notice


    We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

    Last Update: November 17, 2020