The Wrong Answer

I am frequently appalled by the lack of rigor in this craft and this has been recently highlighted to me by a linguistic habit that I suspect comes from a younger generation. ( Sorry guys feel free to have a hack at the old bastard!)

That is the use of the answer Yes/No to a question.  As I pointed out to one of our juniors Yes and No are binary. If architecture is about driving out ambiguity then this kind of answer is unacceptable.  I suspect that this structure is the consequence of not wanting to convey information that might be construed as  “bad news” to ones superiors or clients . If this is the case then the organization needs to take as serious look at the behavior of its leaders because they are responsible for this. They are suppressing information for their own comfort that ultimately the organization will pay for.

Answers, particularly architectural answers,  are not about making the boss feel good. They are about logically and concisely passing on information.  As the mediation gurus say it is neither good nor bad it just is. If you can’t handle that then you’re not leadership material and I suggest you get out of the way because things are hard enough without the irrational bullshit.

For those of you with an academic inclination I suggest looking up Jerry Luftman’s work. His work on alignments suggests a set of maturities that an organization must develop and guess what’s  top of  his list … communication!

Anyway, I’m going to finish off with a list of similar useless communicative structures and what they really signify. I wonder how many you’ve encountered this week? If you’ve got any favorites I’d like to hear them.

  • Just …. As in just do this or that … I haven’t thought it through.
  • All …. As in all you need to do is …. I haven’t thought it through.
  • I think …. As in a response to how does this work? … I don’t know.
  • Well basically … I don’t have a clue
  • I’d like … I ‘m not sure what, but something like … I don’t have a clue
  • I want … I want this or that … I don’t know what I need
  • Oh! it works like that! …. I was bluffing before I don’t really know anything about it
  • The specification could be interpreted in different ways … its not a specification or I haven’t actually read it and I was bluffing before.
  • It’s in the design … As in how does this work? … Don’t ask me I was hoping someone else would figure it out!



1 Comment

A Reference Architecture for Enterprise Architecture


First I have to declare that while I’ve never worked with Phil I have worked in the same organization and I do know him. So with any conflict of interest covered off we can now get down to business.

There are lots of books that will offer either directly or discursively a reference architecture. But typically these focus either a particular technology or problem domain. This book is different its focus is EA as it says in the early pages it is an aid to learning how to do EA.

Despite what the Open Group would have you believe there are many architectural methodologies around and in my humble opinion one of the best is Scott Bernard’s EA3 Framework. (Reviewed on this site).

One of the problems that confronts,  particularly inexperienced architects, is tackling the chosen framework. What techniques need to be applied? Where should the effort be concentrated? And often, after not very long, why are we doing this bit? It’s about this time that having lost their way that projects typically reach crisis point.

What this book does is give you nine succinct sections, one for each layer of the model. Each section is an about twenty pages of good hard executable advice. Many of the questions could be and have been argued ad nauseam  leading projects into the analysis paralysis that is the fate of so many projects. For example “Don’t labour on the shared enterprise and business services”, in two paragraphs the book  puts the issue to bed and that’s typical of its no nonsense approach. One feature I like is that the Conclusion and Summary chapter is only one page.

Following the nine sections are a series of appendices that include an audit model, lists of questions and examples and some suggested reading. Unlike many appendix which are kind of the author’s bottom desk draw there is some real gold in these particularly for the new architect.

While this book is written with a particular methodology in mind and that in itself limits its applicability that should not be used as an excuse for ignoring it. This is a book for Enterprise Architects with a lot of hard won wisdom in it that will earn its place on your bookshelf. Highly recommended, for all sorts of reasons.

Woodworth, P.A. 2013, A Reference Architecture for Enterprise Architecture, Phil Woodworth, Sydney

ISBN: 9780646595276

1 Comment

Quality or Over Engineering?

Recently I’ve spent a lot of time investigating a system that’s been around for about ten years. Like many systems the developers are long gone and the system, ticking over reliably, has been ignored.  Well its time to replace the system and also like many other similar systems no one actually knows what the thing does! As usual the documentation shows little sign of maintenance and inspires even less confidence. There’s only one thing for it, you have to go and read the code.

This proved to be more difficult than you can imagine.  Besides there being no comments in the code, remember that old habit? At every turn every possible function had been abstracted sometimes three or four times. Component after component turned out to be little more than a container for the next  level of function.

Don’t get me wrong I’m as keen on the separation of concerns as the next architect.  But, in this case the result was a ridiculous ratio of functional  code to packaging that simply made comprehension more difficult. Well I got to thinking  about how this came about. The developers had plainly written the code for maximum reuse and extensibility, the problem was that ten years later none of it had been used and the resulting complexity and a lack of  documentation made the system almost incomprehensible.

So the question  must be asked when is it quality and when is it over engineering?

No Comments

So What Makes You an Architect?

The other week, I’m being deliberately obtuse to spare some the embarrassment, I had to engage with a number of people, some in my organization others from outside.

What struck me was that everybody was an architect! But wait a minute I thought are they really?

The first architect I encountered was a Java architect. All he wanted to do was change my spec into the easiest possible code to write. That’s not very architectural. No he wasn’t an architect he was a developer I concluded.

The second architect I engaged goes under the title Enterprise Application Architect. Sounds pretty grand! Problem is I’ve known this guy for over twenty years. He has no technology foundation. He couldn’t program his micro wave. His entire career has been spent in management! He wasn’t even a particularly good project manager. He’s not an architect he’s a manager.

Anyway as the week progressed I was called on to hire an “architect” . Unfortunately, there was no shortage of applicants. But as I plowed through them I came to the conclusion that they were mostly developers, the odd project manager and a couple of escapees from the call center.

So it being Friday afternoon and me being exhausted by my fruitless search I thought I’d take a different tack. Like all good architects I’d concentrate on asking the right question.

The next applicant’s CV boldly declared he was an experienced architect. By this stage this was like a red flag to a bull.

My opening question was “Do you have any certification? Not that I’m convinced by that. “No” . “Have you been on any architecture training courses?”. “No”, was the slightly sheepish response. No surprises there.

“Okay, have you ever read a book on architecture?” I could see the poor guy was desperate to say yes to something. And for a moment I saw it in his eyes, but then he thought better of it as no doubt the possible follow up questions started to occur to him.” Actually no”.

“Do you actually have a business card that says architect?” Not that I’m impressed by that either. A very sheepish “No”.

Sensing blood, I honed in. ” So you have no training, no experience and you can’t even be bothered reading a book on architecture.” I paused for dramatic effect, after all it was Friday afternoon.

“So what makes you an architect?”

Well, that was it it he got up and left. I guess he wasn’t an architect.


How To Measure Anything

How To Measure Anything


Intangible value and Enterprise Architecture are two kindred topics. Accountants would have us believe that if you can’t value something it has no value. Which is kind of hypercritical when you consider that the biggest number on a balance sheet is usually depreciation and that’s a guess! Anyway if you find yourself in the predicament of having to assess the value of the seemingly unknowable  then this book might just be the help you need.

There’s nothing radical in this book, you have probably seen it all before. But here it is all thoughtfully put together in a single volume with some telling questions, that need to be asked before you start measuring and topped off with a bit of method. I do like a good method.

The book consists of four sections Measurement, Before You Measure, Measurement Methods and Beyond the Basics which contain fourteen chapters in about 260 pages. The topics cover the purpose and meaning of measurement, the amount of measuring you should do, the type of measuring, risk, Monte Carlo simulation through to information  economics.

I’m by no means an expert in this field, but then neither is the average architect. So I’d suggest that while this technically isn’t an architecture book it does cover a relevant and often tricky topic and so is a useful addition to the arsenal. Particularly if you get into one of those what’s the value of architecture bun fights.

Hubbard, Douglas W. 2007, How To Measure Anything Finding the Value of Intangibles in Business, John Wiley  & Sons Inc, Hoboken, New Jersey

ISBN: 978-0-470-11012-6

No Comments

Can it get any Worse?

A little time back, I’m being deliberately vague which is a sin for an architect, to avoid embarrassing the presenter it’s not their fault. I had the somewhat dubious pleasure of attending a vendor briefing. The vendor in question had just been acquired by a very big software company and was on a road trip pushing their wares to their new owner’s clients.

In the past I’ve been very critical of the decline in the quality of IT education and have bemoaned the replacement of the battle scarred technical specialist with professional presenters. Who while very slick know nothing. The passing of the war story is a great loss to IT education.  And I’ve long since got over the simple but satisfying pleasure of deviating the presenters from their scripts just to watch them flounder.

This particular vendor seems to have taken the deskilling thing to new, even lower level. Not only was the presenter none technical, but the whole presentation was played back from a laptop complete with pauses for pre programmed witty comments.

It was agonizingly compounded by the presenter’s demographic.  She was a least twenty years younger than the next oldest person in the room and almost incomprehensible with every other phrase being “you know” and “like”. I’m sure her CV says great communication skills. The problem was we didn’t know, that’s why we were there and we certainly didn’t like it!

For all you vendor’s out there that see architects as sales barriers here’s the take away. Being served an pre canned mediocre pitch by an technically incompetent and verbally challenged presenter regardless of how cute she is isn’t going to win any architect over!

Now was that really a surprise?

No Comments

Documenting Software Architectures

“There is no significant meaning to the arrows between the boxes”.  Ain’t that the truth! Perhaps more readily than any other profession IT architects reach for the whiteboard marker to try and explain themselves. It’s amazing given our limited symbolic repertoire, typically  boxes, arrows, clouds and stick men that we so often fail to drive out the ambiguity. Only recently I was reminded of this  when a colleague surprised me with his interpretation of a “read” arrow! Does the component read the data or does the data flow from the source to the component?

Perhaps the emergence of Archimate  has reduced the significance of this work, which is now quite old, but it is undeniable that documentation is still a challenge in many organizations and that’s not just limited to getting the budget to do it.

The book opens with a chapter on the role of architecture before covering off the basics, viewtypes,  styles and symbols, which it supports with seven pretty useful rules of documentation. That are worth repeating here.  Write from the readers point of view, avoid repetition, avoid ambiguity, easier said than done. Use standard organization, record rationale, keep the documentation current and review for fitness of purpose.

The book then pursues a three viewtype model. Module, Component and Connector and Allocation with extensive chapters on each.  These it supports with a chapter on “Advanced Concepts” which tackles the thorny questions of  how do you know when a description is complete, what to do about variability and dynamism and creating a new style. This is followed up with chapters on  View Selection, Documentation Behavior, Building the Documentation Package, before closing with a look at artifacts from RUP, Siemens 4 Views, C4ISR, ANSI /IEEE standards and RM-ODP.

Documentation is an important, but often neglected aspect of architecture. Reading this book will certainly get you thinking about it, even if you don’t agree completely there’s some thought provoking content.

Clements, Paul, Bachmann, Felix, Bass, Len, Garlan, David, Ivers, James, Little, Reed, Nord, Robert and Stafford, Judith 2003, Documenting Software Architecture Views and Beyond, Addison-Wesley, Boston


ISBN 0-21-70372-6

No Comments

Four Rules of Engagement

You know how it is, you say stuff and you don’t expect it have any effect because you’ve said it over and over and no one’s listening. Well, did I get a surprise! Catching up with a couple of guys I’d done a project with quite some time back one of them ambushed with my own words ( Thanks Mikie).

Apparently, I’d given them the old this is how I’m going to run this project speech. Which I honestly think is a bit of a stretch, as I don’t like giving speeches at the best of times. Anyway they insisted that I  record for posterity my four rules of engagement and where better to do it? So here they are:

1) I do care what your problem is. There is someone who has had it before, but if you don’t tell me we can’t find an answer for it.

It’s simple really there’s always a solution.

2) Don’t let me put words in your mouth.

You see this all the time, the architect stands there talking to the client saying yes, yes, we can do that  and in the background the technical guys are all shaking theirs heads going no, no we can’t. It’s best to nip some ideas in bud.

3) If you don’t understand what I just said, don’t let me off the hook!

I was at a briefing once on a very large project listening to the senior architect explain the solution. He was pretty slick, but when he’d finished and rushed out of the room I turned to a colleague next to me  and asked did you get that? No, he didn’t and I’m guessing that no one else in the room did either.  If people are not understanding what your saying it’s not their problem, it’s yours. Too often I’ve seen architects ditch and run like that and the answer is always the same. They can’t admit that they don’t know all the answers.

Not knowing everything is okay, provided that it is openly conceded that there is an issue and that everyone understands that. But, it’s not okay when it’s done a s a means of avoiding the hard questions. So, if I don’t know the answer at least make me acknowledge that openly. It’ll save a stuff up later.

4) If I tell you something that’s wrong tell me it’s wrong.

I may simply be wrong or things may have changed, but do not allow the misinformation to continue to be propagated. Boy, could this have saved me some heart ache over the years.  I don’t accept truth by authority, not even when I’m the authority.


So there they are for what they’re worth. I hope you’re happy now Mike.



1 Comment

The Zoom Factor

Typically the EA books I review are a summary of the author’s heuristic experiences; they provide viewpoints, models and tools for managing the challenges of EA. Fewer authors opt for an holistic approach; perhaps these books are best described as being about “approaches to EA” rather than methodological detail.

Zoom Effect is unique in the way it places the reader at the centre of a discussion about developing the Platonic (in the philosophical sense of ideal form) master architect. While the book could have  slipped every easily into being just another light weight methodology book the author has successfully fused perspectives, personalized the topic and sharpened our focus by engaging our self interest, a clever twist. The Zoom Effect is an EA book dedicated to developing you and accelerating your career and that’s different!

The book is divided into five sections: Set Your Foundation, The Process Driven Architect, Realize Your Soft Skills, Propel Your Perspective and Achieving Architectural Altitude. As you might gather from the titles this book’s aim is to apply an Architecture Development Methodology to your career. The five sections containing twenty one chapters with around ninety topics are covered in a little over 320 thematically organized pages supported by checklists and self assessments to keep you focused and on track.

As one might imagine with only three or so pages to each topic there’s very little actual method in this book. But that’s not the point; there is a lot of clear thinking and straight talking delivered in a very matter of fact and easy to read style. Where the book goes a little too methodological it can be disappointing; the Gap Analysis topic for example isn’t going to set the world on fire. But, it really doesn’t matter. It doesn’t detract from the book’s value, which is in its promotion of the ethos and ethics of architecture rather than the mechanics of method.

The book succinctly; and in my opinion rather refreshingly, calls out the shortcomings of TOGAF and perhaps, all formal methodologies for that matter; without disrupting the narrative that being a good architect is the sum of many tacit skills and it does this without becoming limp. The Zoom Effect is kind of Zen meets the Zachman Framework.

Anyone who spends time on architectural forums and has noticed that there’s always questions about education on them will instantly know that there’s a place for this book. This is a book that’s time has come. Even if you are a well established architect it’s well worth reading.

This is a book that you can start your library with, but it would be unfair to label it as an introduction or an architectural text book, it’s so much more than that. If you are looking specific advice on how to progress your career I don’t think that you’ll do better than this, highly recommended.

Evans, Sharon E. 2010, Zoom Factor for the Enterprise Architect, Firefli Media, Winnipeg

ISBN: 978-0-9812609-0-7

No Comments

Zachman’s Framework II

I recently received an updated version of the Zachman Framework from the Zachman Framework Associates in Toronto. I must say that Stan Locke and his people at Metadata Systems have done a great job renovating this iconic artifact and I unreservedly recommend that you update!

Well done guys!

No Comments