Four Rules of Engagement

August 7th, 2011

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.

 

 

The Zoom Factor

May 4th, 2011

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

Zachman’s Framework II

January 24th, 2011

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!

http://framework2.ca/

What’s really going on in architecture – Update 3

January 8th, 2011

One point emerging from the research is the importance of architecture being in alignment with the business. Which on the face of it seems logical. But here’s the rub; how do we know this is true? Why do we believe this?  Who told us it is so? And if it is so obvious why can’t we define alignment?

Those of you who are bewildered by this kind of Socratic investigation might like to consider taking part in the research which ca be found at: http://angryarchitect.limequery.org/

We can pretty well guarantee that it’ll throw up some questions that will get you thinking!

Enterprise Architecture for Integration

December 8th, 2010

I’ve wanted to get my hands on a copy of this book for a numbers of years and it didn’t disappoint me. Written by one of the doges of EA this 500 page tomb will have no doubt attracted more than its fair share of detractors.

In this world of short attention spans almost anybody who pays more than a passing nod to Zachman seems to be immediately labeled as either too academic or simply too methodologically heavy.  If you’re of this ilk then this is not the book for you. However, if completeness and rigor are the heart of your philosophy then this is a book for you.

The book opens with the obligatory evolution of EA chapter, trotting out the usual stuff you’d expect. And then it shifts focus to Finkelstein’s real passion in a chapter entitled Using Enterprise Architecture for Enterprise Integration. It is in his treatment of data and meta data in particular that this book makes its contribution. Data as the fine grain of integration is its underlying theme. Perhaps not surprising for Finkelstein.

Part one literally covers off the business end of EA with chapters on Strategy Maps and Balanced Score Cards and business planning.

Part two discusses methodologies, SDLC, EA and Governance are all covered. It also takes a look at DoDAF, Modelling, Alignment and Business Normalization and even screen design. But its real contribution for me is the “Business Driven Data Mapping for Integrated Data” chapter.

Part three is a reasonable, but perhaps half hearted technology overview, but by now the book has made its point. But, there is an interesting after thought about the semantics of messaging that is worth your consideration.

On the casual to rigorous scale this book is definitely off towards the rigorous end and this will not make it popular with those who have yet to suffer sufficient pain to realise that there is no substitute for rigor.

A book for the technicians, highly recommended.

Finkelstein, Clive 2006, Enterprise Architecture for Integration, Artech House, Boston.

ISBN 1-58053-713-8

Just Flippin’ the Black Swan Burger

November 29th, 2010

I woke this morning to hear the news that a certain bank was in its fourth or was it the fifth day of computer difficulties. Apparently some branches had stayed open all weekend so that their customers could get some cash.

No doubt, by shear determination the bank will overcome its issues. And no doubt when it’s all over it’ll instigate the usual LEAN, ITIL or whatever reviews to “nail down that process” so it doesn’t happen again!  The problem with this approach this that it will not happen again; ever hear of the Black Swan Theory? But something will happen and it’ll be just different enough to escape that new “nailed down process”. When will they get it?  Process is no substitue for an engaged skilled team of professionals.

Thinking about this problem, because that’s what good architects do. The following occurred to me. I’ve never worked for this parcticular bank, but I’ve had the pleasure; and it was a pleasure of examining at length some of their training documentation from the late nineties. I can tell you that they had everything, career paths, skill sets, selection criteria, everything you can imagine all beautifully laid out for everyone to see.  They were aiming for excellence!

So, how could this stuff up happen in such an excellent organization. Well after talking with some ex-insiders the story goes. That at about the time they had everything down pat. There was a change in management. It became all about cost and the first things to go were the training and development budgets. The next thing to go was many of the excellent people, seeing as they didn’t want to work in an organization that was rapidly becoming unexcellent.  As you can imagine this accelerated the decline dramatically; not only were good people lost, but the whole culture of excellence went into terminal decline.

One of my contacts related the moment, the exact moment when the bank went from being a place that he was proud to work in to, “just another bunch of wankers.”  He asked his manager why his training course had been cancelled. The answer, “look we’re not into all that skills  BS anymore it’s too expense! It’s all about process now.  Just go back and flip the burgers!” Besides the understandable hurt of this insult, this change was followed by a slow but  steady decline in real wages and conditions (like taking the instant coffee away). Well the management thought (oxymoron perhaps) people weren’t as skillfull as they used to be and they’re not nearly as loyal; so why pay them so much? And so the spiral continued. Flipping burgers and doing the back ups.

What process can never do is engage your people the way that skills development does. When you flip the burger you’re not engaged. I wonder how much the bank did save?

What’s really going on in architecture – Update 2

November 28th, 2010

The production survey has now need up since late October and we have a couple of things to report. The response has been good; particularly when you consider the commitment need to tackle the monster, we have respondents from, Australia, Canada, Colombia, France, India, Iran, Israel, Netherlands, New Zealand, Romania, Russia, Sweden, Switzerland, UK and the USA.

So far I’ve made a couple of observations. First, only three female architects have participated, plainly we need more female participants.   Secondly a number of people have commented on how thought provoking the questions are!  Which is very pleasing as not only are  we doing some research, but it seems that the survey has provoked discussions in a number of architecture teams about how they do architecture, which can only be good. It seems that we’ve achieved some unintended give back already!  I’d be very interested in hearing how these discussions evolve and any consequences.

Once again I’d like to thank those who have invested the time and effort to battle through the survey and urge those of you who have partially complete surveys to complete them.  To those who keep “meaning to get to it” to do it!    Remember in architecture there is always something that has to be done, before the first thing can be done! Sometimes you just have to do it!

The survey can be found at: http://angryarchitect.limequery.org/

Just and All the Anti-Pattern of Architecture

November 19th, 2010

It’s one of those phrases that sticks in your head, I can’t remember where I first heard it or even if I’ve remember it correctly. But it had an instant impact and it’s stayed with me ever since, “never confuse activity with progress.” I wish I could claim authorship of this little gem, but alas that belongs to someone wiser than I.

Sitting in an architecture meeting the other day I could sense the growing frustration of the project’s sponsor and then it came both barrels in the one sentence … “look we just need a  (insert  any noun you like here) and all we have to do is (enter the appropriate verb here)” … there I thought the complete  JustAll anti pattern.

Just and all are like red flags to me these days they along with the phrase “I think …” (instead of I know) are absolute sure fire signs of incomplete thought. The people uttering them are invariably demanding action. What they fail to realise is that the problem isn’t that they aren’t doing anything, but that they don’t know what to do! Rather than critically analysing the situation and working out what’s required they abandon the use of their frontal lobe and give in to their primeval “flight or fight” response. Now this is probably a very good survival trait, but it isn’t architecture. Which brings me to another, no doubt misquoted old saying “decide in haste and repent in leisure.” Seems some people never learn.

Information Systems Transformation

November 2nd, 2010

This book consists of a little theory which is a touch on the light weight side and a good 300 pages (out of about 420) on ten cases studies. The theory is concise and pithy asking the right sorts of questions to set the context for a transformation project. Given the nature of such projects and their often unique circumstances I don’t think it’s fair to expect much more in this department. The sheer diversity of transformation projects makes it difficult to develop any theory or even  generalize patterns.

The real strength of this work is its case studies they cover a very wide gambit. There are air traffic control systems, higher education systems, military systems and a bit of good old COBOL re engineering.  The case studies include MUMPS, COTS and a 4GL project, in all they’re a pretty eclectic collection which highlight the complexity of this problem space.

If you are involved in a transformation project I’d suggest that you read this book as part of your preparation, you are unlikely to find a perfect fit. However, the depth and variety of these case studies will undoubtedly provoke  some thoughts and prime you with some good questions.

This is a book for the architect leading the transformation. He’ll have to extract the relevant lessons for the planned transformation from the case studies; there’s no cookie cutter here and there are many things to consider.

This is a good book, whose time is now. While it perhaps has only a limited audience it is undoubtedly a useful tomb. It’s surprising how little good literature there is on transformation.

Ulrich, William M., Newcomb, Philp H. 2010, Information Systems Transformation,Morgan Kaufman, Burlington.

ISBN 978-0-12-374913-0

Making EIM Work for Business

November 2nd, 2010


I’ve noticed that over time the importance that architectural methods ascribe to data seems to shift. For some authors data is  just the stuff that gets processed for others it is the center of the universe.  Needless to say both approaches have consequences.

This is a methodology book, but with a twist. What it proposes is a complete architectural methodology specifically developed with Enterprise Information Management in mind. One I think that could be adopted without compromising for example your integration architecture.

It blends elements of SDLC and architectural concepts like maturity models, frameworks, principles and road maps into a cohesive whole.  It includes sections that are typically thought of as being in the realm of the data architect like Enterprise Taxonomy and topics that one would usually consider enterprise issues like governance.

The book is little over 500 pages in 30 chapters . The first few chapters introduce the usual issues around data, is it an asset? Is it fuel? And sets some definitions. Then if moves on to explore the challenges of EIM. These chapters are effective without being too academic and would serve as a good primer for anyone trying to come to grips with the topic from a management or strategy perspective. Only chapter eight is a  bit of a disappointment at three and half pages “The Economic Conundrum of Information” does its best, but does manage one little gem “Remember there is is not a single CEO who will tell you information is NOT a critical asset …”

These chapters are followed by a ten or so chapters some 300 pages of detailed methodology with numerous examples and loads of good questions that you will have to ask your clients. It will take some time to internalize this methodology and the author acknowledges this by devoting chapters to sustaining and aligning EIM.

While this book might be criticized by the hard core data architect as not technical enough there is no escaping its usefulness as both a pragmatic methodology and a means of educating and aligning the business in particular. This is a book for Chief Architects, Data Architects, C level executives and any well read architect. Recommended!

Ladley, John  2010,  Making EIM Work for Business, Mogan Kaufmann, Burlington.

ISBN 978-0-12-375695-4