Software Fortresses: Modeling Enterprise Architectures
- By Roger Sessions
- Published Feb 24, 2003 by Addison-Wesley Professional.
- Copyright 2003
- Dimensions: 7-3/8x9-1/4
- Pages: 304
- Edition: 1st
- Book
- ISBN-10: 0-321-16608-6
- ISBN-13: 978-0-321-16608-1
Register your product to gain access to bonus material or receive a coupon.
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:
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
Online Sample Chapter
Guards and Walls of Software Fortresses
Sample Chapter(s)
Click below for Sample Chapter(s) related to this title:
Sample
Chapter 7
Index
Click below to download the Index file related to this title:
Index
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:
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
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.
2. Diagramming Software Fortresses.
3. Transactions.
4. Drawbridges.
5. Synchronous Drawbridges.
6. Asynchronous Drawbridges.
7. Guards and Walls.
8. Treaties.
9. General Fortress Issues.
10. Internet Fortresses.
11. Business Application Fortresses.
12. Legacy, Service, and Treaty Management Fortresses.
13. Software Fortress Design Review.
14. Case Study.
15. Postlude.
Glossary.
Index. 0321166086T01292003
Book
This publication currently is not for sale.
Online access to books, videos, and tutorials from Addison Wesley, Prentice Hall, Cisco Press, IBM Press, O'Reilly Media and others - starting as low as $22.99. Learn more and start a free trial.
Account Sign In
View your cart