Angry Architect

I’ve been reading articles by Daniel Minoli for some years now, so it was with some anticipation that I opened this book. It has about 450 pages and two parts. Part one, The Logical Level Enterprise Architecture, Business Process Modeling and SOA. Part two is the Infrastructure Level, Migrating to State of the Art Environments in Enterprises with IT Intensive Assets: Network Virtualization. Not quite the longest title I’ve ever encountered, but I did have to write it down.

There is an interesting contradiction in that the book lists 17 frameworks and standards associated with EA and provides a mathematical definition of an architecture, a degree of rigor that is rare. But, then it covers off the “Official” Enterprise Architecture standards; not very well, in less than ten pages. Perhaps that’s a reflection of how much influence these standards don’t have.

Part one covers Zachman to Business Process Modeling and Service Oriented Architecture Modeling. All reasonably well connected and illuminated with simple but adequate examples while exposing the reader to ideas like MDA, BPML, BPMN, XML, UML, WSDL, SOAP, ESB’s and Service Registries. All at about 10,00 feet. While the book explains the find-bind-execute paradigm it isn’t deep enough to discuss service granularity.

Then almost suddenly at about page 220 the book becomes a hardware overview. It’s all about SAN’s, fiber links and evolving network technologies. Which I contend is too deep for managers and not nearly deep enough to be useful. The next thing you know you are mapping the OSI comms model to the SOA Networking Architecture Framework. (SNAF) and talking about REST. Makes me wonder what the author’s been working on recently. Finally, the book finishes off with an equally shallow section on Virtualization and Grid computing in a strangely unsatisfying way, its almost as if the author was in a hurry to finish the book.

The book is intended for CIOs, CTOs and senior managers and it says so. Basically it is a simplified summary of the current state of EA without the applications. Its of limited use to architects and just detailed enough for managers to get by with; if they don’t push their luck.

Minioli, Daniel (2008), Enterprise Architecture A to Z, CRC, Press, Auerbach Publications, Boca Raton

ISBN 978-0-8493-8517-9

This is quite an old book now, but glancing around at the current crop of mistakes I see being made it occurs to me that it might be a good time to remind people about patterns. One of the foundations of architecture is reuse and standardization is a means to that end. But where do you get good patterns for something that you’ve never seen before? Well, this book is great start. It opens with what seems a possibly too light introduction to architecture, a problem that it recovers from in stages as it works through what is a pretty good catalog of patterns.

You won’t find all the patterns you need in this book and it clearly states that and it does, not surprisingly, have a bit of a pre SOA feel about it. Which leads to the second observation. That this work is considerably technically deeper than the usual “string em together and stuff on a bus” approach. It contains many UML diagrams and code fragments are scattered throughout the book. The way that these have been arranged in 10 sets of patterns presenting about 50 patterns and supported by three chapters of Narratives (think of these as detail design principles) is what makes this book work.

Inevitably any work as technically detailed as this will be susceptible to obsolesce particularly when you consider the way that the boundaries between application and systems software are being blurred by vendors in pursuit of the next market. But, by and large these patterns stand up well and the fact that you don’t use a pattern doesn’t mean that you can’t learn from it.

Although some time has passed since this book was published its approach, variety and volume 500+ pages mean that there must be something in it for anyone interested in pattern based architecture. You won’t read this book cover to cover, but you should read the narratives once in a while and use part two of the book as a reference.

This really is a book for solution architects and technical leads, enterprise architects and even domain architects probably won’t get that much from it. But should for their own education spend at least a week with it; if for no other reason than improving their risk detection skills.

Fowler, Martin (2003), Patterns of Enterprise Application Architecture, Addison Wesley Signature Series, Addison-Wesely, Parson Education, Boston

ISBN 0-321-12742-0

The book starts with a tight lightweight, but perhaps a little pessimistic introduction to the current EA landscape. But there is no arguing with its key point. That it is managing the complexity caused by moving from an abstract design to the implementation of a physical system that is the major challenge.

As its title suggests this is a very pragmatic work. The first chapter draws together some of the business issues that will influence an architectural design. Here Sessions does a better than average job at summarizing the big business issues that should shape your EA. All too often this sort of detail is overlooked by theoretically orientated works. However, this is also the kind of content that can date a book really quickly, but that’s the price you pay for being specific. The author covers off the Zachman framework, TOGAF and FEA in less than 20 pages and there aren’t that many words on a page in this book.

The book then gets stuck into what I think is its most useful contribution. Complexity, with about 50 pages of pretty good layman’s (as in designed for) explanation of complexity backed up with some math, history and psychology all delivered in a light easy read style. I’d recommend these two chapters to any architect its the things we need to be reminded of from time to time, delivered painlessly.

The second part of the book is literally the quest for simplification. We get about 80 pages out of a total @180 that cover techniques as the author lays out a divide and conqueror strategy based on Autonomous Business Capabilities (ABCs), Enterprise Partitions, a set of patterns and a methodology called SIP (Simple Iterative Partitions). Supported by a typical fictional case study.

Chapter 7 introduces the Software Fortress, which looks to me pretty much like re badged modularity on ACID. I’m not sure why it’s here. I also noticed how SOA (Whatever that is? Fair point) got such short shrift? (Because its IBM?) I was left a little puzzled. But, by then I’d had my monies worth and was happy and it hadn’t been a hard read. I have no doubt that this approach will work, but I am left wondering how well it would work at the big end of town, in the very complex enterprises.

This is not a book to start your collection with and it’s not for managers. It is however, fortresses aside, worth a spot on your bookshelf. From where you should take it down every six months and read chapters 2 and 3 out a loud.

Sessions, Rodger (2008), Simple Architectures for Complex Enterprises, Microsoft Press, Redmond

ISBN 13 978-0-7356-2578-5