Rabidgremlin's
Soapbox

When people used to ask me what I did, I used to say “_I’m a solutions architect specialising in eCommerce and distributed systems_”, this invariably earned blank looks (and killed many a conversation with a potential date). Over time I have learnt to simply say “_I do computer stuff_” and if asked “_what type of computer stuff?_”, I reply: “_Architecture, kinda like an architect that designs buildings, but for computers_”. Most people nod sagely at this point and change the topic of conversation.

To be honest I have just outright lied to them. Modern IT solutions are complex, and a solution architect’s role is far more like that of a town planner, than a building architect. Not only do you need to be able to plan the details of a component (building) but also where they are located, how they are connected (roads and services) and how the whole (town) will grow in the future.

In fact to be an effective solution architect (and beating this metaphor to death), you not only need to be the town planner but you also need to be able to be the whole town. You need to be the builder, the road works crew, the towns folk, the mayor, the police and even the emergency services.

In other words you should understand and be capable of performing all the various roles in an IT project from customer to business analyst, to coder, to tester, to operator through to support.

So here are some tips for being an effective architect and for creating great solutions:

Steal good ideas

****Someone, somewhere is likely to have come across the same problem you are having and they have most likely come up with a solution. Steal their ideas!

Patterns are the classic way of documenting good ideas. If you are serious about architecture do yourself a favour and read:

• Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma Richard Helm, Ralph Johnson, John M. Vlissides
• Patterns of Enterprise Application Architecture by Martin Fowler
• Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions by Gregor Hohpe, Bobby Woolf

If you can, read Christopher Alexander’s books (The Timeless Way of Building and A Pattern Language: Towns, Buildings, Construction) which are where the idea of patterns in things we build originated from.

Make sure you look in unlikely places for interesting ideas. I particularly like computer games. Did you ever think how games such as World of Warcraft can scale to handle 11 million subscribers ? Or how a first person shooter such as Counterstrike is able to keep the all the player’s positions and gun fire in sync across a laggy Internet and with players on opposite sides of the world?

Don’t reinvent the wheel

Need to do logging in your application? Don’t create your own little framework, use an existing one. Same goes for model-view-controller frameworks, object relational persistence layers, rules engines, middleware etc. Buy something or better yet use an open source product.

Not only will this reduce development times and costs but you will leverage off years of careful thought and intellectual property. Do not fall into the “not invented here” trap.

Tinker

As an architect you need to understand what works, what doesn’t and where all the ‘gotchas’ are. The only way you are going to know is try things out, so tinker. See a new framework that looks interesting? Download and play with it. A new product? Get a trail version. A new language? Try it out.

Not only will this help you understand if the thing is any good or not but you are bound to come across ideas or concepts that can be worked into your own architectures.

Use layers

Architect your solutions to have layers. Layers can be applied everywhere from inside a component to between subsystems.

The current pinnacle of layered architectures is the SOA, use it (just ignore the hype).

Have clear boundaries

Within your architecture have clear boundaries around the roles and responsibilities of the components. If you have a component that seems to be a jack of all trades, break it up. Have clear rules about what parts of your architecture is supposed to be doing what and know why, so that you can pass this onto others. This will help maintain the cohesiveness of your architecture and make it resilient to change.

Ask why?

“Why?” is a very powerful (and often annoying) question. If the customer says “_we need 99.999% uptime,_” ask why. “_IT policy says we must use technology XYZ!_” again ask why. In many cases the answer will be perfectly valid, in others you will get a “_because_” or a “ _I don’t know_” answer. Your job as an architect is to come up with the most robust and effective solution that solves your customer’s problem. “Why?” can be very useful in figuring out what that solution is.

Ask who?

Asking who needs to use the solution, often uncovers all sorts of wrinkles and can help drive technology choices and your architecture.

For instance, you are discussing building an application that calculates some product discount rates.

So far it looks like a simple spreadsheet will do the trick.

Then you ask “_Who_” will be using it? “_Our finance guys_” is the answer (still looks like a spreadsheet)… “and all 300 of our call centre staff “(mmm maybe an web page on the intranet is the solution now)… “_oh yes and on our website so that customers can use it_” (OK definitely a web based solution now)… “_of course our partners need access too because they get different rates_” (different rates? All sorts of alarm bells should be ringing now).

“Who?” often leads to questions about security and process, all of which can have a profound impact on your architecture.

Think about the future

When developing an architecture always take the future into consideration. Ask questions like who else could use this service? How many transactions are we going to be doing in 3 years?

This means having an idea what the “big picture” is. If you don’t know, ask your customer, look at projects and initiatives that are coming down the pipeline, talk to other architects, go and find out.

On the flip side don’t get so bogged down into trying to future proof your architecture that you over complicate things and build in features that may never be used. Software is soft, it can be changed.

Do the right thing, not the easy thing

Always try to do the right thing, not the easy thing. Sure the easy fix gets the job done quicker but a solution often lasts for years. “Easy” fixes erode the purity of the solution, break the rules of the architecture and cause all sorts of issues such as opening security holes and complicating maintenance.

Be pragmatic

Sometimes you just have to give up on architectural purity and be pragmatic.

Keep it simple

The simpler your architecture is, the more robust it will be. A simply architecture is also more resilient to change which ensures that your solution will enjoy a longer, less troubled life.

Wherever possible reduce the number of moving parts and communication paths in your architecture. Simplify everything you can.

Have a plan B

Plan A sometimes just won’t work (typically for time or budget reasons). First off make sure that plan A is a dead duck then wheel out plan B. This means you should always have a plan B and more importantly have a good understanding of the ramifications of using it.

When you do switch to plan B, make sure everyone involved understands there has been a change of plan, why the plan has changed and what the new plan is.

Enemy of the state

Look to make your architecture as stateless as possible. Stateless architectures are easier to scale and tend to be more robust.

Draw pretty pictures

As the saying goes “a picture is worth a thousand words” and for explaining an architecture nothing beats some succinct diagrams. Learn the Unified Modelling Language (UML) and use it to communicate your architecture to others.

Remember the purpose of these diagrams is to communicate with others, so don’t use every bell and whistle of UML and make your diagrams hard to understand, that is defeating the point of the diagrams and no one will thank you for showing off your UML skills

I find that starting with a deployment diagram is one of the best ways of identifying the key pieces of the solution.

Don’t be static

A trap that many fall into is to simply model the static aspect of the architecture and they forget about the dynamic aspect of the architecture. Make sure you use sequence diagrams and activity diagrams when modelling. They are particularly good at showing up issues with the flow of information between tiers and the order of events in the solution.

Listen to others

Don’t assume that you know best. Gather feedback on your architecture as often as possible and listen to anyone who has a idea.

If you have come across a particularly tricky problem walk some of your colleagues (and even your customers) through it and brainstorm possible solutions. You will be surprised at the good ideas that are lurking in people’s heads.

Be the bad guy (occasionally)

It is sad but true that we live in societies filled with nefarious people, when you architect solutions, keep this in mind. Take a step back and say to your self “If I was a baddie, how would I break this system?”. Look for issues around storage and communication of sensitive data, authentication, authorization, logging for auditing and potential points of vulnerability in your architecture.

If you are architecting solutions using web technologies then check out the Open Web Application Security Project (OWASP), in particular their development guide and their top ten flaws list.

At the end of the day it doesn’t matter how gee-whiz your architecture is, if you cannot communicate it, then it cannot be implemented. As sad as it may seem the best way to communicate an architecture is to put pen to paper.

Now I’m a big fan of JED (just enough documentation) so when I say write it down, I’m not suggesting you write a small novel but rather you capture all the “important stuff”™ into a document, somewhere between 5 and 20 pages long, with lots and lots of diagrams.

So what is the “important stuff”? I define the important stuff as anything that is architecturally significant. For instance if you are building a web based application and you are using a particular MVC framework then document the fact and stop there. However if the solution calls for you to build your own MVC framework, then you will need more to add more detail and more importantly document why you are inventing your own framework.

As a yardstick your architecture is sufficiently documented if you can give the document to someone and they:

1. have all the information to understand why the architecture is the way it is
2. could go away and implement it

My favourite method for documenting an architecture is to use the Software Architecture Document (SAD) template from the Rational Unified Process (RUP). This template (which actually pre-dates RUP) uses 5 views to document an architecture and is often known as the “4+1 view model”.

The use-case view documents the use cases or scenarios that are architecturally significant i.e. the scenarios that form the key functionality of the solution or cover a risky or tricky part of the architecture.

The 4 other views are then used to show how the architecture supports these use-cases.

The logical view describes the architecturally significant parts of the design, such as its decomposition into subsystems and packages. Classes for significant packages are often documented as are any other architecturally significant classes. Typically only the classes responsibilities, as well as their important relationships, operations, and attributes are captured, in other words the logical view is NOT a detailed design model.

The process view describes the processes in the solution, it describes the communication between the processes and shows the dynamic aspects of the architecture.

The implementation view describes the layers, subsystems and architecturally significant components of the solution.

The deployment view describes the physical (hardware) configuration on which the solution is deployed and run. It shows the physical nodes (computers, CPUs) that execute the software, and their connections (network and protocols). Typically the deployment view maps components and processes to physical nodes.

So there you go, how to be an (effective) solution architect in a few easy to follow steps ;)