Posts Tagged ‘Architecture’

Are we there yet?

24 December 2013

For those parents out there they will be familiar with the cry from the backseat of the car on a big journey, “Are we there yet?” Much like children Project managers have a need to know how far we have to go and more importantly are we there yet i.e. can I mark your task as complete.

Setting out on a journey from Melbourne to Sydney it is pretty easy to know how long the journey will take and more importantly how you are progressing and a fair idea of your estimated time of arrival.

Let’s say you were one of the early explorers and didn’t have a specific destination in mind nor an idea of the terrain between you and where you were heading. Pretty hard to know how long your journey will take or how you are progressing.

Solution Architecture can sometimes be like the early explorer scenario. It usually comes down to how many unknowns there are in the problem space you are working in. Stop and think about that for a tick the length of your journey is proportional to the number of unknowns. So if I can identify all the unknowns there are I will know how big the problem is and a rough idea how long it will take to solve.


This introduces one of my favourite concepts which are known unknowns. Now the first step isn’t to turn the unknowns into knowns but just to identify there is something you don’t know the answer to. A good way to track this is to group these unknowns. You can group them into problem spaces or along functional lines depending on the type of solution you are developing.

This grouping of the solution provides a good way to communicate progress of the design activity. This can be expressed as two components:

  1. Unknowns that I have discovered (Known Unknowns)
  2. A gauge of how many unknowns you think you have discovered i.e. a percentage or traffic lights (red, amber, green)

Just be aware that the role of the Solution Architect isn’t to identify every unknown and it isn’t to turn every unknown into a known.

Known Unknows well these are the points where you do your best work. If you deem the unknown to be architecturally significant you need to get down and turn the unknown into a known and find a solution. If the unknown isn’t architecturally significant at this level of design then you just capture it but don’t need to solve it.

Unknown Unknowns well you don’t know. Looking at your solution there is a cloud of unknowns surrounding it, it is just there. You need to assess all the areas of your solution and look for weak spots, areas that the unknowns can penetrate and invalidate your solution. At these points you can do one of two things

  1. You either do some more investigating and identify the unknown
  2. Or you put a risk or assumption that underpins your design decision. Kind of like an unknown force-field.

So how does that sound as a way of venturing where no Solution Architect has ever ventured before? Pretty simple really isn’t it. Identify the unknowns that will impact you solution. Turn the important unknowns into knowns and find solutions for them. How easy could it be? Now try and get a Project Manager to put those tasks into a project schedule.

Good Luck!


Twas the night before Christmas

24 December 2010

Twas the night before Christmas, when all through the office
Not a creature was stirring, not even a Tester.
The archietcture was drawn on the whiteboard with care,
In hopes that a Shaping Arhcitect soon would be there.

The Business Anlaysts were nestled all snug in workshops,
While visions of requirements danced in their heads.
And the PM in MS Project, and I in Visio,
Had just settled our brains for a replanning session.

When out of the lift there arose such a clatter,
I sprang from the meeting room to see what was the matter.
Away to the whiteboard I flew like a flash,
Tore open a Marker and threw up the flipchart.

The flouresent light on the new-drawn design
Gave the lustre of decoupling to objects below.
When, what to my wondering eyes should appear,
But a Business Sponsor, and eight tinny SMEs.

With a little old driver, so lively and quick,
I knew in a moment it must be the General Manager.
More rapid than eagles his coursers they came,
And he whistled, and shouted, and called them by name!


He sprang to the lift, and to his team gave a whistle,
And away they all flew like the down of a thistle.
But I heard him exclaim, ‘ere the lift door closed,
“Happy Christmas to all, and to all a good-night!”

Architecture and how to mess it up

20 November 2008

Jeff Cohan in a nice little post on Rails Architecture makes a great point about Architecture being one thing but using the architecture correctly is another. He relates it the the architecture of a house or apartment and how you destroy what the architect envisioned when he designed it by putting the wrong things or too many things into the building.

Got to love a good metaphor.

Big Problems and Little Problems

13 June 2008

Listening to an architecture presentation on InfoQ there was an interesting comment made about how an architect should prioritise decisions. An interesting point raised was around the impact of resolving big architecture decisions early in that these decisions allow smaller problems can be easier. The reverse of this is even more significant, in that making the easy architecture decisions before the big ones constrains what decisions you can make to solve you big problems.

This is one of those common sense type statements that is good to make a conscious decisions when creating an architecture.

Australian Archiecture Forum

19 May 2008

The Australian Architecture Forum for 2008 focused on SOA: The New Maturity. Being entrenched in my companies SOA program was interested in what I would be hearing. Unfortunately I found that trying to fill eight sessions on relevant SOA content was a little hard. I did find the Round Table sessions interesting in that I was able to hear of other peoples experience with adopting SOA within their organisations.

The keynote this year was by Ron Todd from IBM on Business Agility which seemed to distil down to adopting a Policy Engine for storage of Business Policies. By capturing the policies in a central engine provides the ability for the business to be responsive to market forces by being able to change these policies quickly. Ron emphasised that a policy is not a rule (aka Rules Engine), a policy seemed to fit somewhere between a Business Rule and a Business Process.

Phil Haynes from Object Consulting presented a great overview of one of his projects that used Restful services but the adoption of URIs seemed to be the real nugget. He spoke of everything having a URI defined, and by everything he meant requirements, people, tests etc. This approach seemed to enable a decoupled project that delivered several benefits. An interesting benefit was that the business could access a URI that represented a report or a function and mash-up a report.

Ron Jacobs presented a great overview of his learning’s over the last three (3) months has he has tried to understand REST. He did callout the book RESTful Web Services from O’Reilly as a great resource of information on rest. The presentation was technical but I did get a better understanding of the structure of rest as an architecture style. I think one of my colleagues was truly lost given he doesn’t have a Microsoft background which did sort of raise the question of the suitability of technical detail at a conference like this. I was very surprised that rest does not consider the schema that a resource supports and incorporate a way to discover this schema.

The Round Table on ‘Your SOA implementation is now a teenager and out of control’ was brilliant we had a great mix of people from different sized organisations that were at different points along the SOA adoption path. The group seemed to have the topics of governance and versioning front of mind with several stories being shared on these topics. Probably as no surprise there is a culture aspect to these topics that means there will always be issues in their adoption.

I did run into the problem of being in a Round Table session where we only had five people in the session. Due to the topic of cloud computing there wasn’t much experience in the room and subsequently no discussion naturally evolved with limited the value I got from the session.

As with these sorts of event the ability to network was great, I managed to bump into some old colleagues and make some new contacts. It is great to have a conference focused on Architects in Australia and a big well done must go to Object Consulting for their organisation of this event.

Sometimes a design just evolves

30 April 2008

I came across an interesting quote in an article about the development environment architect that caught my attention.

The life of a software architect is a long and rapid succession of suboptimal design decisions taken partly in the dark.

I think this really highlights the fact that the role of an architect is part science and part art and you need to balance these two into the process of designing a solution. Two areas that this presents challenges to the architect is in the areas of communicating their design and secondly in being able to shift between the low level design decisions but also keeping an eye on the big picture.

As an architect you are constantly learning new things about the environment that your solution must live in as well as strategic directions that your solution should be cognisant of. As paths present themselves and paths are blocked your design evolves based on these forces, sometimes into a state that maybe doesn’t make sense. At points along the design process it is important as an architect to stick your head up and have a look at the overall solution in the context of the business problem it is trying to address and see if it makes sense i.e. could you explain it to someone and they would agree with your design?

As a design evolves you need a maintain a current view of the design that makes sense, by this I mean that the reason that each design decision has been made is documented. The best way to tune your design is to get feedback from people about the design in the context of their domain (e.g. security or application domains) to identify and address any issues that need to be considered in the design. As you need to be getting feedback on your design from a very early stage you need to make sure that the journey is documented as well as the current state so that people can see why you have made the decisions you have made. Including this information is important if you want to make sure that you don’t revisit design decisions over and over again in your discussions.

Yes being an architect is a high stress environment where you are measured by the quality of your design but are expected to include all factors, known and unknown in your design.

SOAP over JMS…..Not

13 April 2008

I largely work with people with a java background (I have a Microsoft background) so often have to map java terms into something that I understand. Our SOA architecture uses MQ Series as the transport layer for our SOAP messages as apposed to HTTP. The java guys commonly use the term ‘SOAP over JMS’ which left me confused, I understood that JMS is the Java Message Service but wondered why we would use a technology depended transport layer.

Yes I did eventually figure out that the term ‘SOAP over JMS’ is an incorrect description, JMS is a Message Queue API much like System.Messaging is an API in .Net. The term should be ‘SOAP or MQ Series’.

JMS looks something like (copied from Linda’s blog):

ConnectionFactory cf= new com.sun.messaging.ConnectionFactory();
Connection connection = cf.createConnection();
Session session = connection.createSession();
Destination destination = session.createQueue("HelloWorld");
MessageProducer producer = session.createProducer(destination);

TextMessage message = session.createTextMessage();
message.setText("Hello World");

In .Net it would look like:

MessageQueue msgQ = new MessageQueue(@".\private$\HelloWorld");
msgQ.Send("Hello World");

I am not sure if the JMS example could be simplified, as indicated above a copied the example.

So if you year the term SOAP over JMS you know know what is actually meant.

Architecturally Significant

17 March 2008

The completed architecture for a solution is influenced by various project and environmental forces. Having navigated the minefield to get the design just right the next step for an architect is to document the architecture. Requirements, Issues, Risks and Dependencies all influence the architecture but when documenting the architecture only the architecturally significant ones are important.

A project will have a set of detailed requirements but when documenting these in a Solution Architecture Document you need to filter and roll up these requirements to a set that is architecturally significant. Each functional and non-functional requirement that has influenced a decision in the architecture should be documented but no more. The same goes for project issues, risks and dependencies document only the ones that have influenced the architecture.

Where this becomes interesting is that no functional requirements may have influenced the architecture and as such you may not need to document what the project functionally is going to do but only what non-functional requirements need to be met. You could design an architecture for a web based CRUD application (e.g. Web Server & Database) that is correct but where what data being manipulated is irrelevant i.e. the functional requirements are not architecturally significant. In this scenario you may include a level of functional requirements e.g. a use-case diagram to give context to the solution.

Focusing only on the architecturally significant aspect of a project is important so that you firstly reduce the amount of noise and secondly emphasis the factors that have influenced the final architecture. The number of possible architectures for a solution are infinite if there are no influencing forces (e.g. constraints). Taking the reader through all of the influencing forces that are architecturally significant will eliminate options hopefully culminating in one architecture being the right one which is the one you have documented.

As you are documenting your architecture be sure to constantly asking if what is being documented is architecturally significant.

A conceptologist by any other name

7 March 2008

A discussion we have been having at work is the value of having so may different types of Architects. I blogged about the new Client Architect role we were creating and my thought on that. Well the conversation is moving the other way where we are considering removing some of the roles and collapsing then down.

I have been reading Alexander Kjerulf’s post on More death to job titles and have taken a shining to the generic title of Conceptologist. So I have reclassified my role as Conceptologist, obviously I will need a pay increase to reflect my new role. 🙂

Client Architect

15 February 2008

I new appointment for a Client Architect has just come over my desk, mmmm so what does a Client Architect do? According to the memo, a Client Architect:

  • Leadership of the infrastructure architecture
  • Representative in the infrastructure architecture community
  • Rationalising and resolving multiple potentially competing technical priorities
  • Manage and lead the development of project architectures

So what is the difference between this and a Solution Architect or an Infrastructure Architect. As a community we can’t bo doing ourselves any favours when we invent roles which don’t really add any value. Within our team we have five(5) types of Architects and we still haven’t agreement on who is responsible for what. As per the title of this blog it is hard enough to define what an architect is let alone all the different specific architect types we seem to like to create.