|
|
|
Home Business Resources
Simple Architectures for Complex Enterprises (PRO-best Practices) (Best Practices (Microsoft))
|
|
|
|
|
Binding: Paperback
Dewey Decimal Number: 004.22
EAN: 9780735625785
ISBN: 0735625786
Label: Microsoft Press
Manufacturer: Microsoft Press
Number Of Items: 1
Number Of Pages: 208
Publication Date: 2008-05-19
Publisher: Microsoft Press
Studio: Microsoft Press
|
|
|
|
|
|
Spotlight customer reviews:
|
Customer Rating:  
Summary: Where's the Beef?
Comment: That's the question I kept asking myself as I re-read Simple Architectures for Complex Enterprises. Let me say at the outset that I'm totally open to the possibility that I missed the point--again!
The book starts off with an interesting discussion of complexity. Ok, not bad. Then, Sessions introduces the set-theoretic concepts of equivalence classes and partitions as means to reduce complexity. At this point, being a math enthusiast, I was well baited. By Chapter 5, where he first begins to discuss the SIP process, I had high expectations. By the time I completed Chapter 6, I was completely disappointed. His fundamental equivalence relations--synergistic and autonomous--are intriguing in their definition, but amount to being completely arbitrary and subjective. I found no real mathematical grounding at all, which is a major premise and selling point of his approach.
After reading about his type system, with its implementations and deployments, I came away feeling that I had read yet another description of how to do a functional decomposition (FD). This time, though, it comes wrapped in terminology that is pedantic. His "laws of partitions" are nothing more than heuristics for checking a FD:
- The First Law basically says that the FD is hierarchical. That is, a node can have only one parent.
- The Second Law states that the FD must make sense.
- The Third Law states that each level of the FD should contain 3-8 child nodes.
- The Fourth Law says that each child node in the FD should be about the same in scope, complexity, and importance as the other child nodes at the same level.
- The Fifth Law is not so much a FD rule so much as it is a statement about low coupling and high cohesion.
I think Roger Sessions is very smart and innovative (e.g., his metaphor of Software Fortresses is very well done). So, I want to give him the benefit of the doubt. But I don't think there's anything new here, folks. It seems to be a rehash of some Structured Analysis and Design concepts and other concepts from the past.
Someone please show me where I missed the boat!
Customer Rating:
Summary: Techniques for high-leverage complexity management
Comment: When building software it is often difficult to step back from the complexity of the solution and consider the big picture -- how the software will fit into the real world. Managing this complexity is a major challenge for the industry.
Simple Architectures for Complex Enterprises addresses how to manage complexity in IT systems at the top level of design, Enterprise Architecture (EA). EA describes how software and processes fit together to provide value to users. Whether EA is more about "design", "requirements", or something else is less important than the idea that the highest leverage place to manage complexity is in the big-picture "systems" perspective that transcends software details.(e.g., what software pieces should be built/bought and what should they do?)
The book lays out some context and history for EA in chapter 1 (35 pages), and then spends chapters 2-4 (70 pages) laying the foundation for complexity management techniques. The author's core EA process (called SIP) is described in chapter 5 (20 pages). Chapter 6 (15 pages) is a detailed case study of a troubled reengineering of the UK's health care IT systems. Chapter 7 (10 pages) is a mapping of the complexity management ideas onto an SOA model from the author's previous work, described as the "software fortress" approach.
Depending on your background and experience level, some parts may be slow or of limited value. However the book's structure allows you to skip over areas that are bogging down without missing value later on. In particular:
- You don't need to immerse yourself in the descriptions of existing EA models in the second half of chapter 1.
- If you are comfortable with probability, equivalency sets, and partitioning, you can skim and skip over much of chapters 2, 3, and 4. There is good primer material in these sections, although the prose is a bit drawn out in places.
- The SIP process can come across as a prescriptive sliver-bullet. The author does caveat the importance of artistic application, but this can seem drowned out at times.
Ultimately the book wins by providing starting points for practitioners to keep business systems simple and partitioned at the highest points of leverage. Although many of the underlying ideas are not new, they are packaged in an accessible, logical way. The case studies, references to current industry debacles, and the authors personal experiences are valuable on their own and make the work an engaging read.
Customer Rating:
Summary: Straight talk on enterprise architecture
Comment: Effective architecture books are difficult to find. The subject is not trivial. And disagreements are prevalent in this space, even on the definition of architecture itself. It seems that more texts on architecture are being written than in the past, but most of the emphasis seems to be on design. While design is important, architectural decisions have far reaching effects on software systems (such as maintainability and scalability) if and when they are ever actually successfully constructed and deployed. Of course, most technology professionals rightly recognize that there exist different types of architecture. Roger Sessions defines enterprise architecture as "a description of the goals of an organization, how these goals are realized by business processes, and how these business processes can be better served through technology". Sessions later offers a simplified definition that it is "the art of maximizing the value of IT investments", and reducing complexity in the enterprise helps achieve these investment returns. To explain how this might be accomplished, the author discusses mathematical concepts, enterprise architecture concepts, and Simple Iterative Partitions (SIP) concepts. Part I of this book discusses the current state of enterprise architecture and presents a look at complexity and the mathematics of complexity. Part II discusses ABCs (Autonomous Business Capabilities) and the SIP process that the author created. While the chapters on complexity start out strong, these tend to get a bit tiresome due to the lengthy explanations of basic mathematical concepts centered around partitions (although the chapter entitled "Enterprise Architecture Today" in which the author discusses the current space alongside succinct presentations of the Zachman Framework for Enterprise Architectures, the Open Group Architecture Framework, and the Federal Enterprise Architecture is very well written). The second part of the book starts a bit slow as well, but chapters 5, 6, and 8 are strong, and if one does not have time to read the rest of the book it is recommended that focus is placed on these chapters. While brief, the pages on project prioritization are especially worth consideration by the reader. Eight default factors are included in the author's typical Value Graph Analysis when determining project prioritization: market drivers, cost, organizational risk, technical risk, financial value, organizational preparedness, team readiness, and status quo. The radar graphs are used in a similar manner to those used in "Balancing Agility and Discipline: A Guide for the Perplexed" (see my review). It is very unfortunate that while the author provides input to the market driver factor, input to the other factors is not divulged. Although this prioritization is not an exact science, the inclusion of this information by the author would have been helpful to make sure the reader is on the same page of understanding. The case study presented in chapter 6 is interesting. While a lot of such material is freely available on the internet, in my opinion more book authors need to start including similar substantive real-world content. The National Program for Information Technology (NPfIT) is the case study. The basic goal of NPfIT is to automate and centralize the massive record keeping that is the backbone of its national health care system run by the British government's National Health Service (NHS). The author discusses how his SIP process could have avoided much of the complexity to the project (that has resulted in failure) by vendors such as Accenture and Computer Sciences Corporation (CSC). Sessions includes some well-worded closing thoughts in chapter 8: "We frequently hear that IT systems are getting more complex, as if this is a natural consequence of living in the 21st century. In reality, however, it is not systems that are getting more complex but system requirements that are getting more complex. It is not the job of the enterprise architect to design ever more complex systems. It is the job of the enterprise architect to resist the temptation to build complex systems." Also: "The paradox about complexity is that it is simple to make systems complex; it is complex to make systems simple. Many people think that it takes a lot of talent to create a highly complicated architecture. That isn't true. It takes a lot of talent to take complicated ideas and realize them in a simple architecture. Anybody can create a complex architecture. It takes no skill at all. Architectures naturally seek the maximum possible level of complexity all on their own. If it is a complex architecture you are after, you don't even need architects. You might as well just fire them all and let the developers work on their own."
Customer Rating:
Summary: Architectural Common Sense
Comment: I have managed to talk to quite a few good software/enterprise architects over the years. When I do, the issues that we often talk about most are simplicity of design and how to manage complexity. In general, understanding that the management of complexity is the fundamental task of architecture is what defines a good architect. This book indicates that Roger really gets this issue. He also seems to get the business alignment issues that are sometimes lacking from architecture texts.
From Roger's advice on partitioning a solution to his advice on implementing a system using an incremental approach everything here is sound and well articulated. This book is a short read but almost definitely worth your time if you are building anything in software from an enterprise down. Much of the principles he professes are the same principles that are important in regular software architecture. Components and object oriented design are merely methods of figuring out internal equivalence classes and appropriately partitioning solutions. Iterative development and some of the new agile principles are based on the same idea he advocates for the enterprise, incremental delivery.
If for nothing else, this book is useful because Sessions is very successful in mathematically proving that many of his ideas should work. Most texts advocating incremental methodologies or problem decomposition can sound evangelical. This book does not.
Overall, SIP sounds like it is a very good foundation for a company's enterprise architecture.
That said, I am sure my advice would mean more if I did enterprise architecture. I hope that it is merely enough to say this.. I am in software development. I have helped provide or provided the technical architecure on quite a few projects. I feel that in general Roger has the core concerns nailed with his book.
|
|
|
Editorial Reviews:
|
|
Dismantle the overwhelming complexity in your IT projects with strategies and real-world examples from a leading expert on enterprise architecture. This guide describes best practices for creating an efficient IT organization that consistently delivers on time, on budget, and in line with business needs.
IT systems have become too complex and too expensive. Complexity can create delays, cost overruns, and outcomes that do not meet business requirements. The resulting losses can impact your entire company. This guide demonstrates that, contrary to popular belief, complex problems demand simple solutions. The author believes that 50 percent of the complexity of a typical IT project can and should be eliminated and he shows you how to do it.
You ll learn a model for understanding complexity, the three tenets of complexity control, and how to apply specific techniques such as checking architectures for validity. Find out how the author s methodology could have saved a real-world IT project that went off track, and ways to implement his solutions in a variety of situations.
Key Book Benefits:
 Presents a model for understanding IT and enterprise complexity  Provides practical solutions for controlling complexity, and shows how they can be applied in a variety of situations  Features a methodology for checking architectures for validity  Explains how to apply simplification algorithms to software systems  Includes a real-world case study that demonstrates how the author s solutions could have saved an actual IT project that went wrong
|
|
|
|
|
|
|
