This is the last book in the Enterprise Engineering Series I had to read. It covers a ton of topics and covers them in-depth. The book starts out with a nice introduction to the author's point of view regarding Enterprise Engineering and Enterprise Governance. It then continues with chapters on Mechanistic and Organismic Perspectives on Governance, Enterprise Essentials, System Thinking, Corporate Governance, IT Governance, Enterprise Governance, and The Praxis Illustrated a case study. One of the things I like most about this book is that it combines corporate governance and IT governance under the Enterprise Governance umbrella. Most larger organizations see IT in a supporting role instead of a strategic ally, which leads to the corporate or business decisions being only partially effective. The business makes their decisions in a bubble that does not provide a realistic view of their true context. Another thing I really like about this book is that it is an engineering book. Some people may not like that. It lays down the theory as well as the implementation of practices. It is very detailed which at times can make for a difficult read if you aren't used to reading engineering books. I have been involved in logistics engineering, electronic engineering, and now software engineering, all three included having to take into account the fact that humans are part of your system. The authors have a very clear understanding that some of the elements included in the engineering of an enterprise are humans and all the little quirks that come along with them. The chapter on mechanistic and organismic perspective on governance really digs into the different perspectives you can expect to find in the minds of the members of an enterprise. The chapter on systems thinking is an important one for any sizable enterprise. Software Process Dynamics is an awesome book on system thinking. The ability to see the changes you are proposing in context where dynamic relationships can be evaluated is something most enterprise architecture initiatives are missing. Using system simulation models they can get a glimps of what impact a decision will have. The only problem I have seen is that system simulation does not work well in immature environments. In order to provide an accurate model, you need to understand the environment you are modeling, and most enterprises I have seen do not have a clear understanding of their true environment. Some time ago I was involved with a technology review for a new project being developed. It was a smaller project being developed by one of the maintenance teams, but still a few months worth of work would be needed to get it in place. We approved some technology and disapproved some. We have an enterprise policy in place for the development language that should be used on any new project, so that was not discussed. We asked for more frequent code reviews because of new technology being introduced into the enterprise. We also planned to use the project as an example project for using the new technology. Three to four weeks into the project we go to the first code review and we find the application being developed in a language other than our approved language. The excuse (notice I don't use the word reason for something like this) was the support team tasked with building the application is not proficient with the current enterprise endorsed language. This pointed out just how immature our IT governance implementation is. We had untrained people supporting software, and now they were implementing new software in an unsupported language. Apparently the enterprise policy on which language to use was viewed as one to follow only if you felt like it. The saddest part of this story is that they were allowed to continue development in the unsupported language. Instead of the project becoming an example to the enterprise on how to implement the new technology, it became the tail of the elephant in the room that the EA group continues to ignore. That elephant being the lack of any real IT governance. The chapter on IT governance points out this problem explicitly. When you take a look at the criteria for evaluating an enterprise the one I am referring to above falls into the category of Incoherent according to this book. That would not be the story you would hear if you went there and interviewed the employees or managers. Instead you would hear about an award winning IT department. The point is that this book will uncover a lot issues with your current environment and it will provide you with the tools to make the changes necessary to improve. It will however be up to you to make the changes. They are not easy ones to make. It will require becoming humble, transparent, and open to change as a whole. Meaning everyone will need to be included. People will need to be retrained and those that are not teachable will need to be let go. All in all I find the wisdom in the book well worth the time and effort it takes to read and digest it. It is very valuable and topnotch information. The entire series is worth reading. It should be mandatory reading far all Enterprise Architects, CIOs, Directors, CEOs, CFOs, Software Architects, Project Managers, and anyone else who needs to understand what a healthy enterprise should look like. All four books currently in the series.

Enterprise Governance and Enterprise Engineering (The Enterprise Engineering Series)

Enterprise Architecture: Creating Value by Informed Governance (The Enterprise Engineering Series)	Enterprise Governance and Enterprise Engineering (The Enterprise Engineering Series)
Enterprise Architecture at Work: Modelling, Communication and Analysis (The Enterprise Engineering Series)	Architecture Principles: The Cornerstones of Enterprise Architecture (The Enterprise Engineering Series)