Past Book Review (August 16, 2008): "Simple Architectures for Complex Enterprises"
Past book review (i.e. posted prior to starting this blog) for Simple Architectures for Complex Enterprises, by Roger Sessions, Microsoft Press, 2008, reposted here:
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."