02/04/2008 by Jon.

This post is part of a series based on the book Documenting Software Architectures: Views and Beyond.

One of the first sections (page xix) is about the picture on the front cover which shows a rather nice sketch of a birds wing. The section discusses the use of analogies and our usual staple of the “building” to help describe architecture. I am as guilty as anyone in using this as a way of explaining what I do. Yes, I do think about the structure of the system/building. No, I don’t worry too much about the colour of the screen background/carpet (apologies to any HCI specialists reading this, I do know that colour on a UI is important but hopefully you get my point).

The authors quite rightly point out that buildings are fundamentally static objects while systems and fundamentally dynamic. In fact most systems fail in their dynamic behaviour rather than their static structure. Hence the use of a birds wing which has a complex dynamic model is a far better analogy for architecture than the building. An excellent insight!

But somehow it wasn’t satisfying as an analogy. For the front cover of a book by architects, for architects, it works well. However when I tried to visualise myself standing in front of a group of business managers talking about bird wings it felt wrong. These people are fundamentally pragmatic and practical. If I start talking about hummingbirds I’m going to lose them. So what would be a good analogy?

Now I come from an engineering background so naturally started thinking about engines and alike. Again this failed the “audience empathy” test. Your average business person doesn’t care much for thermodynamics or metal fatigue. So I tried a little bigger. A car? Better on the empathy test but didn’t feel very business relevant. Then I struck on an idea. What about a bus? They are fundamentally about engineering which is good; we want to be based on good engineering practices. There are dynamic and static elements so it addresses the shortcomings of the building analogy. It has business users (the driver) as well as customers (the passengers). There are business owners (the fleet operator) and a support organisation (the maintenance team). Importantly it also meets the “audience empathy” test. We all know what a bus is, it is a common point of reference.

Now before we get too excited it is just an analogy. A useful way of getting understanding between different groups. This does not represent the birth of a new design method based on route planning and seat colours, but it might just help a little.

So I haven’t even reached the preface to the book and already the authors are making me think, even changing the tools of my job. While I will be using a different approach to theirs, this exercise has made me question what I do. I call that a good start, although at this rate it’s going to take me a long while to read this book!

Posted in Views and Beyond, How to Architect | Print | 1 Comment »

28/03/2008 by Jon.

Following on from my earlier post The Trouble with Documentation I went off and bought the SEI book by Paul Clements et al. I’m now working my way through the book with the intention of applying much of what it says. My hope is that this will help to kill off, or at least calm down, some of the on-going arguments that always seem to ensue. How detailed is high level design? What should we put in the design documentation? So how long is this design work going to take?

If the blurb on the back cover is anything to go by then help is at hand. I’m just hoping that the book can deliver on the promise.

I’m going to try and blog some of the interesting points I come across, mainly so that I don’t forget them, but also to explore them a little more. I’m not going to reproduce the book, that would be both illegal and rather pointless, but I do want to dig around some of the key ideas. I like to think that I’m a fairly practical architect, in that I work on projects with customers the whole time. Having tried out many approaches and techniques over the years I often find that while the theory is great the rigour tends to tail off when you get down to the practicalities. Given the authors and heritage of this book I’m hopeful this won’t happen.

To be continued….

This post is part of a series based on the book Documenting Software Architectures: Views and Beyond.

Posted in Views and Beyond, How to Architect | Print | No Comments »

13/03/2008 by Jon.

It is often said that IT Architects are of a certain breed and in some way different from other IT Professionals.

I came across this blog entry today  which talks about what sort of personalities make "good" architects. Luckily I am one of the types on the list (not saying which one!) which came as something of a relief.

Enterprise Initiatives: Do you have an Architect personality?

While no theory like this is ever perfect, it does have a ring of truth about it. If nothing else it could help someone thinking of a career in architecture decide whether it is really for them rather than just falling into the career like most of us!

Posted in Architecture Career | Print | No Comments »

12/03/2008 by Jon.

Following on from my previous post about Practical Loose Coupling

So what is going on? What has happened to wreck havoc on what was probably a perfectly good set of systems? Let’s try a little exercise to see if we can simulate the effect.

First let us start with two nicely designed systems; System A and System B. System A needs to get some information from System B, for example the price of a product. Now the implementer of System A decides to play by the rules and use the interface already provided by System B. The designer of System B had realised that the price information they held would someday be useful to someone. They included in their design an interface which given a product code would return the corresponding price.

Now not wanting to state the obvious, but are we clear what an interface actually is? Sure it is some method or call you can make but is there a more fundamental point here? The interface is a contract. A contract is a way of saying, if you do this for me, I will do that for you. If you pay me some money then I will design a system for you; or give you a car; or fly you to the other side of the world. An interface contract is no different. If you send me some data formatted in this way, and you send it using this technology protocol, and you provide this type of security credential, then I will give you some data back; or update a database; or whatever. I may also insist that you take another action first, or follow-up with another action, such as a commit, before I will promise to do what you ask. The point is that the interface is far more than the specific call you make; there may be a whole set of activities that we both have to do in order for the desired result. At this point I get a mental image of of two tropical birds taking part in an intricate courtship dance. Wheeling and twirling in just the right way. Ensuring that no foot is put wrong. Unfortunately most interfaces are far less interesting and much less productive.

So back to our example. Our two systems are busy with their courtship dance. System A understands, by way of the interface contract of System B, what it needs to do. It creates a request in just the right format, it invokes the right type of communication technology and presents it credentials. System B takes the request from the communication stack, checks out the credentials and looks at the request. Assuming all is well it will find the price information and put it back on the communications stack and send it on its way back to System A. All is well in the world.

Posted in How to Architect | Print | No Comments »

10/03/2008 by Jon.

Developing good quality architectures is the what the Architect is there to do and there are many good architects who can do this. What often stops them from being great Architects is the communication of their thoughts and ideas. In fairness this is an incredibly difficult thing to do as there are usually many ways of describing the solution and, most importantly, many different readers or stakeholders.

The key point is that documentation is fundamentally about communication. The Architect has a mental model which they need to get into other people’s heads. The medium to do this is documentation as it provides a way of doing this in a communicable and durable way.

What this means is that the first step to good documentation is understanding your audience, also known as your stakeholders. This is where the trouble becomes apparent. What you need to communicate to a software developer is not the same as that for a network engineer. Then there are project managers, technical design authorities and of course senior executives

So how do we resolve this; how do we produce one set of documentation which adequately describes our solution and also meets the needs of our different stakeholders?

An approach which is gaining ground in the architecture world is that of views. Essentially this approach says that while there is only one solution, there is more than one way of looking at it. Some people also talk about the concept of filters or lenses as ways of distinguishing between different views.

The first step in this process is to list out your stakeholders; not all of them, just the ones who you need to communicate with. Then try to understand what they are looking for, what do they need to understand? You can then shape your deliverables around their needs rather than yours.

The approach is not perfect and takes some getting used to, but the outcome is something that is far more valuable, useful and hopefully appreciated!

If this sounds a little theoretical then there are quite a few resources to help you get started.

The Open Group Architecture Framework has a whole chapter on architecture views which can be found here.

The SEI have embraced the concept of views and have a template plus other information here.

Some of the SEI team have also produced a book on the subject which is available at Amazon.

There is also an ISO standard which much of the above but unless you are really interested in standards the above resources will be more use. The page on Wikipedia provides more details

Posted in How to Architect | Print | 1 Comment »

10/03/2008 by Jon.

Loose Coupling is good. Tight coupling is bad. A familiar mantra for any system designer. The problem with loose coupling is that it is incredibly fragile. Without constant care and attention it can easily whither and die. The challenge that the architect often faces is justifying what can often be a nebulous concept to a project manager who has a deadline to hit. So what exactly is loose coupling and how can the architect stand up for it?

To help get some clarity it is a little easier to talk about the opposite effect. Tight coupling is all too familiar to anyone who has worked in a legacy environment; the effects are all too evident. Systems that can’t be changed because it will break something else. Database schemas which can’t be updated because someone has knocked up a quick query rather than use the agreed interface. Changes that take so long and cost so much to implement that there is no business case for carrying them out despite them clearly being the right thing to do. Sound familiar? Well that is tight coupling in action.

In the next post we’ll look at an example to see if we can understand what happens with real-world systems.

Posted in How to Architect | Print | 1 Comment »

26/02/2008 by Jon.

Welcome to the Conceptech blog. Here we will try to provide advice and insight on the world of IT Architecture, especially for architects working at the front line of business projects.

Posted in General | Print | No Comments »