I have had the pleasure of meeting John once and was more than a little entertained by tales and enthusiasm and I can only say how sad I am that it has come to this.

http://www.zachmaninternational.com/

Call me cynical but, I’ve always had a irritating suspicion that vendor provided certifications were at best marketing strategies run for the vendors’ benefit or at worst clumsy attempts to brain wash the technical community. While vendor certification for their products does on the face of it seem to be a good idea. I have always had problems with vendor driven architectural certification.  After all I maintain that good architecture is technology agnostic.

My observation is that most corporate education these days seems to have devolved into mouse driving exercises delivered by specialist trainers who do no more than follow the script. Testing the knowledge boundaries of these  “instructors”  used to be one of my favorite pass times. But having recently spent three days locked in a room with a woman who read slide after slide to me for hours on end I can tell you that I’m well and truly over that as well. Exactly when did teaching become piece work?  But, hey I’m probably certified on that product; they gave me a piece of paper,  now if I could only remember its name?

Vendor certifications are not the only certifications that make me raise an eyebrow. Let’s face it the purpose of certification is to establish the certified’s credibility.  Certifications that can be gained by attending a few classes; particularly ones you pay for, are suspect. That’s like learning to drive by correspondence, fine until you get into the traffic!  I mean really, call center dude one day enterprise architect the next. Thank god we’re not in medicine.

Then there are the internal corporate certifications. The problem with these schemes is that they are subject to corrupting pressures like directives to certify so many architects in a given time. Certification is reduced to a rubber stamping  and rigor abandoned in pursuit of a KPI! Can you imagine accountants doing that? The self appointed wise sit around and certify each other! It’s all just a little bit too cozy to be credible.  One such scheme was described to me; by someone who would know, as “not so much a certification process as an exercise in creative writing.”  Beautifully put I thought.

It’s not difficult to imagine a scenario in which the educationally unskilled and inappropriately experienced certify their mates to meet a KPI.  What’s worse is that some organizations then accept this certification as sufficient authority to automatically impart their own certification on the  same sorry candidate! You’d think people would be more careful with their brands these days.

In a world that increasingly confuses appearance with substance and where the truth has become negotiable, as architects we must be on our guard against such nonsense. All I can say is that Microsoft’s decision is a step in the right direction. “Good on you Microsoft” … never thought I’d say that.

If you’ve read any of Schekkerman’s other books this will have a familiar feel to it and it’s not just the cover design. But don’t let that put you off. This isn’t just a rehash of previous books. It’s the development, refinement, collation and summation of a whole body of work from IFEAD, some of which has been presented in previous books.

Without labouring the point; and let’s be honest here far too many architects like to labour for too long over the arcane, Schekkerman has produced a very useful volume. In it’s own words it ” focuses on EA maturity, processes, results, frameworks, methods, tools, roles and responsibilities”. It even manages to touch on issues like stakeholder management and offers a pretty comprehensive eleven aspect maturity model. That even if you don’t agree with the MM  concept you have to concede has some merits.

This is a cohesive set of ideas on EA obviously developed with considerable dedication and attention to detail. There is always the danger of such works being afflicted by intellectual myopia, particularly when penned by self proclaimed thought leaders. Refreshingly however, Schekkerman is not impervious to the ideas of others. He seems quite happy to appropriate and incorporate proven established ideas; a trait that I’m always on the look out for. There really is no single source of truth.

This book is @ 380 pages with plenty of diagrams and focused tightly written paragraphs, which unfortunately all too often degenerate into bullet points. You just know that there’s more to be told. But, then the book would be 3800 pages! So, I guess it’s a pretty good compromise.

This book claims to be for Enterprise Architects, managers and C level executives. I’d go further and suggest that all architects can learn something from this book. This is a good book to start your library with more rigorous and less SDLC centric than most and more accessible than many  of the “Euro” architecture books. Recommended.

Schekkerman, Jaap 2008, Enterprise Architecture Good Practices Guide,Trafford Publishing, Victoria, British Columbia

ISBN 142515687-8

I can’t deny it I was shocked when I received my copy of this book. It’s a big soft back book 30 x 21 cms but only 120 pages.

And the claims on the back cover “This books covers every detail”, that’s a big claim I thought. It goes on “Professional resources and underlying technology are provided in detail.” But, they are big pages, perhaps there’s a lot of small print, I thought. You can’t imagine my disappointment when I discovered that the first 67 pages look like screen prints of three Powerpoint presentations! My first reaction was how much did I pay for this? At $5 it would have been too much!

The three presentations you’ll get for your money are Establishing Federated IT Architectures, 36 slides with bullet point notes and pointers to the second half of the book. A tutorial on the Zachman Framework, 13 slides with practically no notes. And a 10 slide Executive Overview that wouldn’t fool Mickey Mouse. To add insult to injury the slides aren’t even color, wouldn’t scan well so if you wanted to use them you’d have to recreate your own version (ready for use?); if you’re that desperate give up now you’ll never make an EA. What’s more they don’t even have a consistent style!

The second part of the “Handbook” appears to be five or six first year papers on architecture, none of which are more than superficial and some of which; you guessed it are mostly bullet points, widely spaced in large font with no consistent style, doesn’t inspire confidence.

D for content, F for price and A for stating the obvious.

Handley, Jeff 2008, Enterprise Architecture Best Practice Handbook

ISBN who cares!

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

]]> http://www.angryarchitect.com/?feed=rss2&p=249 3 http://www.angryarchitect.com/?p=232 http://www.angryarchitect.com/?p=232#comments Wed, 31 Mar 2010 23:24:50 +0000 Imhotep http://www.angryarchitect.com/?p=232

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

Is it technical skill, experience, communications skills? I’d suggest that it is credibility. Where does this come from, obviously it can have it’s foundation in any of the skills noted above and probably many more that I’ve not mentioned. However, I’d argue that ultimately, credibility is about trust. It’s about people trusting the architect. Trusting that he’s telling the truth and that he is giving them as accurate and impartial assessment of the topic as is possible for a mere mortal.

Impartiality is an important lesson that too few architects seem to have learned. Architecture is not about who’s right it’s about what’s right for the client. One way that we ensure impartiality is by having objective processes that minimize individual bias  and provide transparency for decisions. By no means are any of these processes perfect, traceability makes the process transparent and so when someone is unhappy with the decision the reasoning behind it can be explained. By this means a good architect protects his client’s interests  and indirectly his greatest asset his own credibility.

I’ll give you an example. Recently a technically competent, but frankly rather arrogant architect at a client of mine made a “judgment” call. Without consulting the rest of his practice or recording his process. This resulted in him  excluding a particular vendor from a selection process for a pretty much commoditized capability. His reason he’d seen the product “years ago and it wasn’t that good then. I doubt it would have changed..” he went on “besides I don’t like XXXXXX”.

The problem with this is he’s lazy he’s made a call based on information that he admits is old and hasn’t  given XXXXXX a chance to change his mind. This isn’t what your boss pays for when he hires you. This architect has no doubt done this many times and because his client trusts him he can get away without due process, he is abusing their trust.

This particular architect however has come unstuck. The vendor unhappy with the unfairness of the decision has forced a meeting with higher management and because the architect has been  lazy and not a little bit arrogant he has no defense. There is no recorded assessment process, no defined principles, just his say so. He’s looking pretty vulnerable right now, his management are more than a little embarrassed and have insisted that a proper assessment be done. Architecture is about rigor, being told by executives that you haven’t been rigorous enough should be a humiliation for an architect.  Now I wouldn’t be surprised if this guy fixes the assessment process so that the vendor can’t win, because for him it’s about him being right. But, the fool doesn’t seem to realize that the real damage has been done. From now on every decision he makes will be questioned by his executive because he was lazy,  biased and has betrayed their trust.  He’s credibility is now shot.

One day the even bigger meaner bank who were in the habit of bullying the very large cowardly, cheapskate outsourcer decided that they needed a disaster recover drill. Actually, being a big mean bank they really couldn’t care less, but the one thing they sought of feared, a slow moving  almost toothless regulator on the prowl. And given how banks had recently almost ended the world as most us know it, they were almost sensitive to the idea of what people might think and were afraid that the slow moving almost toothless usually ineffective regulator might actually bite them as they too were being scrutinized because the recent near death experience of the world economy was seen by not a few people as being at least partly their fault. So a scenario of the cheap, mean, cowardly, unwilling and usually ineffectual came to pass. All things being equal there were no great expectations.

Elmo the architect was assigned to certify that this drill was effective. Which all sounds very professional. But is really the big mean bank’s way of mitigating risk, of passing the risk to the people best able to handle it. Which is short hand for any barely credible idiot greedy and dumb enough to take it! After all the one thing the recent near death experience of the world economy had demonstrated was just how good banks were at managing risk and what good fellows they were when it came to accepting responsibility and the tax payer’s money.

Anyway, Elmo’s a pretty good architect, a diligent keeper of notes and he knows a thing or two about this kind of drill. A real contrast to the usual half arsed preparation done by the  very large cowardly, cheapskate outsourcer. While this sounds good and I’m sure the large cowardly cheapskate outsourcer exploits Elmo’s diligence for marketing purposes to win business, his rigor really isn’t part of their business plan. The appearance of it is, but not the actual detail, after all who really cares? Well, Elmo cared because Elmo had certain values another area that the recent near death experience of the world economy had exposed as a strength of the banks and the finance industry in general.

So, on the night of the drill, Elmo in attendance observes carefully, taking notes, lots of notes, lots of good notes with time stamps. At the end of the drill the certification decision isn’t difficult, because Elmo had taken notes, lots of notes, good notes with time stamps. “No chance” he says! And referring to his notes, his good notes he reals of f reason after reason way the drill failed to the very large cowardly, cheapskate outsourcer’s account team and goes home to sleep with a clear conscious. He’d done his job and it wasn’t his problem to fix. The account team will have to talk to the big mean bank. It was  going to take some money to fix these issues.

The very large, cowardly cheapskate outsourcer’s account team have been bullied so often by the he big mean bank that the mere thought of doing anything other than genuflecting to the bank’s very whim  provokes a panic attack! What’s worse they know so little about IT  that they can’t actually explain to the always grumpy big mean bank what needs to be done. This made the big mean bank even angrier than usual and the very large cowardly, cheapskate outsourcer’s account team responded by being even more pathetic than usual.

So, filled with fear and unable to explain themselves the very large cowardly, cheapskate outsourcer’s account team resorts to the only behavior it knows works. Why not, it works on them; they start trying to bully Elmo. At first this was a low level cowardly bullying; as you might expect, which Elmo, being an easy going kind of architect  just takes as folks under pressure being a little snappy. But, he doesn’t change his position. No certification for all these reasons. Well, the very large, cowardly cheapskate outsourcer’s account team are a gasp a techie talking back to them! Well they weren’t sure if he was or not because he kept using words they don’t understand. But, it can’t be good because he won’t say yes. And this was really bad because it meant that the big mean bank would shout at them again and be very unhappy and they might have to spend some money and bring down the profit on the account which would make the boss of the very large cowardly, cheapskate outsourcer  also shout and not give them some money, they might even miss a payment on their Porsches.

There’s nothing for it the problem must be addressed they decided with remarkable determination for a team that generally only genuflects. We’ll take this problem by the horns! The architect must change his assessment. Then the big mean bank will be happy and we we’ll make our Porsche payments and all will be well.

Problem was Elmo had values one of those was professionalism, increasingly rare I know and often a liability, but believe me highly desirable.  Well you can imagine the sought of thing that went on as the increasingly hysterical very large cowardly, cheapskate outsourcer’s account team tried the “truth as a social construct” approach on the positivist objectivist  trained architect. True to his word Elmo could not be convinced, after all he had the notes, lots of notes, really good notes with time stamps.

So, very large cowardly, cheapskate outsourcer’s account team waited until Elmo went on leave and convinced some other architect; who hadn’t been present at the drill and had no notes, of the utility of socially constructed alternative realities and all was well. The big mean bank stopped shouting and they could make their Porsche payments.

And they all would have all lived happily ever after if it were not for the slow moving almost toothless usually ineffective regulator actually catching up with the game! See how it doesn’t happen until the last chapter. Now they also kept notes, really good notes with date stamps. And one of these notes said that last time this drill was done it wasn’t that flash and what’s more you the big mean bank better make sure that the very large cowardly, cheapskate outsourcer tests this stuff more thoroughly next time to prove you are taking us seriously or else we’ll bite you!

Well, the big mean bank is insisting that the  very large cowardly, cheapskate outsourcer should take the slow moving almost toothless usually ineffective regulator’s bite on its behalf as they certified the drill! Meanwhile the very large cowardly, cheapskate outsourcer’s account team are all polishing their Porches  and looking the other way while the certifying architect is polishing his CV. The slow moving almost toothless usually ineffective regulator is impatiently tapping its feet and polishing its teeth. The only one who sleeps soundly is Elmo.

Moral of the story, keep notes, lots of notes with timestamps and don’t let  people transfer their responsibilities to you even if they do wear expensive suits.

This book is about IT Architecture and is a methodology based on a technical five domain framework; Applications, Information, Network, Platform and Operations. It addresses each providing pretty much the currently accepted practices for each domain.

This means that over time the book will probably not age that well, but it is a fairly sound summary of the current state of play. It includes areas and concepts like wireless, ESBs, ODS and even SOA and virtualization, in a concise but not very detailed way.  After all it is only 180 pages and there would be books with more  pages on every one of these topics.

The  philosophy of  blending  “strict rigor and organic innovation”  sets this book a little at odds with the Euro architects, but it does produce an easy reading and informative text.  The book opens with the all too common Why EA? sell chapter;  in which he covers off the usual agility verses cohesion issues.  However, I think it is in the next two chapters on Architectural Principles and Governance in which the book makes its real contribution.

Principles seem to be a problem for a lot of architects. Particularly, connecting them in a meaningful way to the design and development domains. This book offers what may be the best twenty odd pages linking business models and strategy to principles that I’ve seen written for the layman.  He goes on to back this up with a simple, but better than average chapter on governance.  In which he rather timidly pokes a stick at the “managerial behavior” elephant. I can almost feel him constraining his frustration to the suggestion of a few metrics for the architectural review board’s performance. Unfortunately, he doesn’t have much to say about handling architectural exceptions, but then again not many authors do.

This is a good book, current, and easily read,  a little lightweight and while some sections will with time become obsolete others contain sound advice obviously born of experience.  Not deeply technical or academic it is a more than a fair attempt to bridge the business IT divide. I think most architects would find something useful in this book.

Reese, Richard J. (2008), I/T Architecture in Action, Tyler Westcott

ISBN 978-1- 4363-0505-1