The Contact Protocol & my first RFC
[Update]: I have created contactprotocol.org which now holds the draft specifications.
About ten years ago I had a couple of interesting ideas but due to sheer laziness on my part I never did anything with them.
One of these ideas however keeps popping back into my head and so finally I’ve decided to do something about it.
The original idea is very very simple: wouldn’t be nice to have a URL that points to information about you ? You could give this URL to people and they would always be able to find you.
Now of course it’s 2009 and the idea is slightly more refined and so I give to you: the “Contact Protocol”… It works as follows:
- you give out a Contact URL which looks something like contact://host.com/xyz . This URL can be put on business cards, email footers, websites etc
- the URL can then be used to retrieve your up-to-date contact details. If your details change you simply update them in one place and anyone who has your Contact URL can retrieve them.
Now obviously you would be able to type the URL into a web browser to lookup someone’s details but that is only one use.
How about an email client ? Just add the Contact URL for someone into your address book and voilà your email client will always have right email address for them.
What about your mobile phone ? Add a contact URL for a contact and the device can use it to figure out which phone number to use when you call them.
Instant messaging, same deal…
Pretty nice… at least I think so.
So what the heck is an RFC and how does it fit in with your crazy idea I hear you ask ?
Well I want the Contact Protocol to be widely used and the easiest way to do this is to make it a standard. On the Internet standards are defined in request for comments or RFCs. This practice has been in place since the Internet was born.
The RFC process is looked after by the IETF (Internet Enginnering Task Force) and most RFCs are written by this group but anyone can write one and submit it for consideration so this is what I have started to do.
It is however not entirely straightforward, RFCs have specific format, language, style and content requirements. Check out the RFC style guide (formatted as an RFC itself). Luckily the IETF have provided the xml2rfc tool which takes an xml file and generates a correctly formatted RFC, this makes things much simpler.
So I’m currently enthusiastically hacking away on my xml file, I’ll let you know when I have something to look at.
mPass article on NZ Herald
My Google Alerts just turned up this very nice article about mPass on the NZ herald site.
It is always nice to get good press about things you have worked on.
I like the comments too:
I downloaded the Air New Zealand mPass a couple of months ago and have used it successfully a number of times. It is a fantastic application and has sped up the already fast check in process with Air NZ. its great to see “our” airline is right up there with technology and has made the whole tiresome process of checking in simple and enjoyable. PS – the iphone rocks. just a shame about the data charges.
and
Excellent idea ! Keep it up, Kiwi’s – show the world we can make things better, faster and more convenient.
mPass for iPhone is live!
mPass for the iPhone is now available. If you are a lucky iPhone owner then you can download the application here or visit the AppStore and search for “mPass”
For those of you who are iPhone-impaired (like me), here are some screen shots:
-
- Welcome Screen
-
- Flights list screen
-
- Boarding barcode
-
- More options
Its all about clarity
Over the last 15 odd years I have been involved with dozens of IT projects of all shapes, sizes. Recently I have been reflecting on why some of these projects were a dream and delivered successfully, whilst others were a complete nightmare and went horribly wrong.
An obvious factor is the size of the project but that does not ring true. I have been involved with huge projects that went like clockwork and small projects that just couldn’t seem to get off the ground. The same is true for projects with complex or simple domains; projects with untried technologies or projects with proven technologies.
So what was the differentiator?
After much pondering I have come to the conclusion that those projects that were most successful had a good deal of clarity. Clarity in what needed to be done, why it needed to be done and how it was going to be done.
So I’ve come up with a new catchphrase (which I intend to bandy about at every opportunity):
“CLARITY leads to FOCUS, FOCUS leads to DELIVERY”
Actually I really wanted to use VELOCITY in there somewhere and DELIVERY is just so so unsexy so perhaps its still a work in progress but I digress.
So what do I mean by clarity ? Well pretty much exactly what it’s definition says “The state of being clear in thought”.
Of course this isn’t a new concept, which is why we have the waterfall process with its BDUF (big design up front) approach. Unfortunately this process actually has the opposite effect because it tends to silo the project members around particular phases and then uses big fat documents as a means of communication between these silos. At each step of the way clarity around the why, what and how is typically eroded or even (as I have seen in some cases) corrupted, all of which leads to the classic customer reaction ,when they see their software for the first time, of “What the hell is that, thats not what I wanted”.
This of course is where agile processes come into play with their sleek processes that allow a project to deliver efficiently and successfully. Of course without clarity an agile project degenerates into a mess, with quality going out the window in an effort to meet iteration deadlines, constant quick fixes, a stressed out team and a failed project.
So how do you about gaining clarity?
The best approach I have seen is to get as many of the people who are going to be involved with the project into a room to work out the why, what and how. The group should include the stakeholders, end-users, subject matter experts, architects, UI designers, testers, business analysts, developers, project managers, infrastructure bods. Pretty much anyone who can add value to the process.
Don’t panic, even for large systems the effort involved for this is measured in hours and days, not weeks and months. I would however, suggest you find a good facilitator to keep what is typically a fairly large group of people focused.
Here are some techniques that I have used or seen used to nail down the why, what and how:
To capture the why, write a vision statement. It doesn’t have to be book. In fact put a limited on the length of the statement such as “25 words” or “3 sentences” or if you want to be particularly nasty: “7 words”.
To capture the what, you can uses any number of techniques. I find that visual ones work best (and are easily done on a whiteboard) so use-case diagrams, storyboards or UI wireframes and entity or domain models are the order of the day.
In a similar vein, to capture the how, nothing beats a deployment model and some sequence or activity diagrams (all in UML of course).
So to make your IT project a success make sure you have clarity and remember
“CLARITY leads to FOCUS, FOCUS leads to DELIVERY” :)
Check out Scott Ambler’s Agile Modelling site which covers some of the techniques above and has a bunch of other practical and interesting ideas.
How to be an architect
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”(tm) 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:
- have all the information to understand why the architecture is the way it is
- 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 ;)
