Customer Reviews

Simple Architectures for Complex Enterprises (PRO-best Practices) (Best Practices (Microsoft))

5 star:		(4)
4 star:		(3)
3 star:		(1)
2 star:		(1)
1 star:		(1)

 

 

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!

The general approach to any grand IT problem is to break it down to smaller manageable pieces. Pieces that our pathetically puny brains can contain and work on at a time. Any decent software developer would have known that. And yet, we still continue to produce massive, monstrous, monolithic code that is a complete beast to interpret, comprehend, and modify. In other words, a mesh of _unmanageable_complexity_. There is without a doubt such technical misshaping contribute significantly to the schedule and budget overrun in way too many large projects, and ultimate failure.

But what am I talking about? This book is not about software applications. As an enterprise architect, Author Roger Sessions takes us up several floors to show us where he believes all these complexity evil germinates - the failure to control the complexity of IT inter-system communication across the organisation. He writes this volume to explain the problem of complexity can be illustrated via mathematical models, and purports that the application these mathematical exercises and further concepts of organisation will help divide the enterprise into simple easy pieces.

_That_ is a rather mighty claim. Is this for real?

Roger Sessions starts out strong. He begins mentioning existing methodologies and frameworks used to organise architectures in the present industry and highlights rather glaringly the missing piece in all of them - the deliberate effort to ensure the output of the work is simple. The next two chapters quickly move on present some simple real-world scenarios (like a rubik's cube, chess games, team and store organisation, etc) and then the math behind them, on how dividing them - partitioning - into smaller pieces of a bigger whole helps to solve the problem they present in a much less troublesome manner. The mathematics introduced is simple enough to understand and convincing. But somehow the lessons would be re-taught every now and then; I found the repeated explanations to be redundant and approaching incessant. It is almost as though the author fears the readers may not be convinced enough and needed reminders. Or there is the assumption the intended audience largely failed elementary math in school.

As convincing as the principles behind the math are, my disappointment set in when the transition from pure math theory into real-world business modeling began. If you think it sounded too good to be true that real-world architecture can be tackled with simplistic mathematical models, well, it is. Even Roger Sessions himself admits that real-world circumstances is in fact, not that simple. The problem with the absolute black-white nature of mathematical theory is it excludes many (grey) inter-object relationships or channels that real-world organisations would inherently possess; they cannot be blindly ignored. Take for example, the Five Laws of Partitions

'First Law of Partitions - Partitions must be true partitions.
'Second Law of Partitions - Partition definitions must be appropriate to the problem at hand.
'Third Law of Partitions - The number of subsets in a partition must be appropriate.
'Fourth Law of Partitions - The size of the subsets in a partition must be roughly equal.
'Fifth Law of Partitions - The interactions between subsets in the partitions must be minimal and well defined.

With such vague "laws" I predict a chasm of opportunities for unending subjective debates over what "appropriate", "equal size", "minimal", or "well defined" can truly mean when it comes to discussing how to partition a real organisation into smaller units. Therefore the fourth chapter's technique of Autonomous Business Capabilities (ABC) did not resonate well with me as I pondered how this applies to real departments and divisions. It is just not that simple. However, Roger Sessions' intention is squarely - and rightfully - focused on breaking things down simple enough to benefit the _business_.

On a side note, I found his deliberate avoidance to discuss application systems somewhat isolative. As a software developer, I find many of the principles he puts forth are directly applicable, and even taught, at the level of software architecture and design. Like it or not, the lifeblood of any enterprise is the myriad of software applications; keeping their design simple is as important as keeping the enterprise simple. In fact the SIP (Simple Iterative Partitions) process he recommends resembles Agile practices a lot. Somehow, I get the feeling Roger Sessions has forgotten failure in IT projects is contributed by many things happening at all levels, not just enterprise architecture alone.

It is difficult to label this book as truly seminal; due to the various falling pieces, I cannot feel the utter greatness. But don't be deceived - it has been a good _mind-stretching_ exercise (not mind-blowing). Roger Sessions has presented some eye-opening ideas that allowed me to gain new light in this argument for simplicity. His message is clear - there not enough people consciously considering simplifying things they work on; and accomplishing things by smaller projects of iterative sequence. I wholeheartedly agree on this. If the word "simplicity" never flashed across your mind (are you reading this, CIOs, CTOs, and architects???) while you were thinking through architecture or design, you need this book to yaw yourself in the right direction.

OVERALL RATING: 7/10
GOOD: Refreshing perspective; interesting model & approach for architecture; gets the point across
BAD: Repetitive; model not 100% mapped to real world; concept not 100% new; the IT problem spans across more than one area

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.

I enjoy Roger Sessions and read his newsletters and past books. This book is on par with other Roger Sessions writtings. Roger's work is very well thought out as well s logical.

What seems to be missing, for me at least, is the clear cut solution.

The computer solutions world is complex by default. Most computer professionals are so wrapped up in current implementations, politics, issues, self-centered solutions, etc., that the clear-cut path foward is impossible to find. It seems like the Roger Session reader is a lone wolf crying in the forest. The organization around them is not interested.

Yes, the book finishes with the path forward, but, for me anyway, does not give the arguments needed for change.

There needs to be the simplistic points to wake up the ITD departments. That is what I see missing in Roger's books. BUT, I AGREE WITH HIS REASONING AND SOLUTIONS, COMPLETELY!

Now on to this book.

The first part of the introduction is probably the key to the rest of the book and best addresses the general complaint listed above. Everyone, in every IT department, should read this section.

The first chapter is an overview of system architecure in general. This chapter alone is worth the price of the book, to me at least. Too many organisations focus on a very small part of architecture and that small part as the enterprise solution. This chapter encapsulates the what, why, and failure of enterprise architecure methodology.

The next couple of chapters discuss complexity and proofs of complexity. After that, he discusses partitioning, why partitioning is benefical, and explains his partitioning process.

I appreciate Roger Sessions thought process and encourage all computer professionals to read.

Maybe I'm missing something, but this book seems flawed. I agree that simple is always better. I also agree that breaking complex problems into smaller pieces (partitions) is a good way to make something more manageable and increase your chances of success. But....

The idea that breaking things into partitions that are isolated seems flawed. Consider this example in the book - you have a bunch of executives trying to figure out lunch. Rather than having the group try to decide, you break them into five different sets of execs. Each determines part of the meal, such as appetizer, main item, or dessert.
Each group can figure out there piece because there are fewer factors involved, so you'll get lunch resolved and decided exponentially quicker.

Okay, but...

Most pieces of a larger project don't happen in isolation. As such, it isn't as simple as this tries to make it. If you end up with a group of executives eating a meal that is mish mashed together, then you are likely to have a bad lunch. While a bad lunch is tolerable, a bad project is not.

An equally flawed example is that of using an emergency response system. The author comments that it would be bad for a surgeon to give directions on removing a victim from a car. That is a bad example, but indicates the slight way this book seems 'off'. Instead of that example, the author should have commented that if a surgeon tries to operate before the victim is removed from the car....

There are a lot of interesting tidbits in this book, but as some of the other reviews said, there is a lot of redundancy, a lot of vague comments, and a lot of common sense too. The math is interesting, but not enough to make this a great book.

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."

It is quite common these days to hear someone saying that enterprise architecture has failed to provide expected value. Some people declare that EA is dead. Not that anyone agrees with that, but you can't deny that certain degree of disillusionment does take place. Practitioners are increasingly disappointed with apparent lack of focus of `classic' all-your-system-are-belong-to-us EA frameworks (read TOGAF) and desperately trying to find a leaner, more value-driven way of doing things.

This book is essentially about post-framework EA. It isn't new, in fact it was published 3 years ago, but, like a good wine that gets better with age, the book becomes more and more relevant with each passing year. Roger Session courageously redefines what good enterprise architecture is about. In his view, there's a single fundamental root of every notorious issue in modern enterprise IT such as business misalignment, untimely and unreliable information, soaring costs. The root is complexity that poisons everything if not properly controlled. The goal of this book is to present a proper set of thinking tools that enable an architect to understand, measure, plan and contain the overwhelming complexity of an enterprise.

First few chapters are dedicated a theoretic introduction to the subject of complexity. Author draws from combinatorics and set theory to illustrate several techniques to battle complexity: partitioning, simplification, and iteration. The less math-savvy you are as a reader, the more challenging the reading would be, but at the same time the more you get from the book. Anyway it's not a rocket science, so everyone could make sense of it.

The rest of the book is mostly dedicated to author's own lightweight method on controlling the complexity of enterprise architectures which is called Simple Iterative Partitions (SIP). From its point of view an enterprise is seen as a hierarchical composition of autonomous business capabilities (ABCs) that partition both modules of business and software systems that support them. A nice feature of SIP is that it draws a clear line between enterprise and solutions architecture and doesn't attempt to get into the domain of latter, but rather helps to define boundaries of systems that need to be developed or acquired.

In addition to that there's an entertaining case study of complexity (mis-)management given on an example of notorious multi-billion atrocity of NPfIT programme that is run by British National Healthcare System since early 2000s. A superficial application of SIP demonstrates that certain programme-level decisions made in the past were fundamentally wrong from the complexity control perspective, and a better way of achieving the goal is elicited. Of course devil is in the detail so I wouldn't take the conclusions deadly seriously; however, for a sake of method demonstration it is really valuable perspective.

I found the book to be easy to read. In fact it is quite short, less than 200 pages of actual content that is concisely summarized in the last chapter for further reference. It could be even shorter if author took out lengthy introduction on the subject of EA in the first chapter. It is completely useless to most readers because it presents yet another overview of Zachman Framework and TOGAF that is too short to be practically useful on its own and doesn't add any value as it is not referenced in the book later.

In summary, I would suggest reading this book to anyone practising EA as it provides a completely unorthodox perspective, which is always good since it feeds your critical thinking. On the other hand if your professional interests are closer to tin, e.g. technical architecture, you may find this book of less interest as it lacks any specifics or technologies. It isn't a book that you'll keep at your desk, but it is definitely a smart and enjoyable reading that changes the way you look at everyday things.

(This review was originally posted on Enterprise Systems Engineering blog -- see profile for URL)

Sessions correctly identifies the real enemy of IT; complexity. Exploring the facets of simplicity and its applicability to Enterprise Architecture makes this book well worth reading. If the author repeats himself, it's only to bash this important concept into our thick skulls. Let we never forget! I wish more books explored this topic.

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.

When I brought this book, I was seeking for a book that talks about Enterprise Architecture, and I found this book as a perfect book for my need ... especially to use it in my master thesis, but what I have found is far away from the big phrase of Enterprise Architecture.

The book started well, spoke high-level and gave good introduction about some major key-words of what we are dealing with in work, but actually after the introduction I felt that I'm just reading an intro book to start studying IT, its just like those 00 books that we was taking when we enters bachelor programs, far away from IT, giving simple and trivial examples, talking about non-IT world more than IT, and even it didnt talk technically at all.

The book talked well about complexity and how to go to simplicity, but it kept far away from "Enterprise" and "Enterprise Architecture", it didnt talk about solutions architecture, simplicity in Enterprise design, best practices about how to architect our enterprise, I was expecting to read about how to create enterprise solution and how to design an enterprise architecture, how to distribute business among projects according to the use of business, distribution of data and how to set-up enterprise on servers ... etc, but what I have found in the book is no more than a talk about minor principles and mathematics for start thinking to learn computer science

If you want to pre-start reading about enterprise architecture, and u didnt get involved into a real project development or dont have any technical experience, this book may be good as an entry for you to start thinking in learning architecture