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.
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.
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.
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.
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);
connection.start();
TextMessage message = session.createTextMessage();
message.setText("Hello World");
producer.send(message);
In .Net it would look like:
MessageQueue msgQ = new MessageQueue(@".\private$\HelloWorld");
msgQ.Send("Hello World");
msgQ.Close();
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.
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 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. 
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:
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.
Ted Neward has had a series on Pragmatic Architecture on the MSDN site for a while, definitely some interesting content which as Ted points out is quite technology-neutral.
When working on an agile project there are four principals from the Agile Manifesto that should focus the project/team. When considering the role of the Architect in the project you still have to conform to these principals. Traditional Architect engagements are at the start of the project with an exit usually shortly after the high level design is complete and some evidence of the implementation of this design has been reviewed.
There is a great article on The Shiny New Agile Architect that caught my eye and does a great job of explaining the responsibilities of the Architect. Much the same as for any project, that is run under any methodology, the Architect is focused on the impact the Non-Functional Requirements have on the final solution. Vikas Hazrati does a great job of distilling this down to some great traits.
The trait about architects building tests to test the architecture decisions is a very interesting one.
An Agile Architect writes system-level tests that stress the architecture.
Unit testing is a major component of any successful agile project it allows the team to respond to change in a controlled manner. Knowing that you can change your code and know that any functionality that you had previously been built still works is a powerful thing. Being able to make changes and know that your architecture still meets your non-functional requirements is even more powerful. Non-functional requirements are all about the quality of the software, having this baked in at the start through testing means it isn’t neglected. Retrofitting a design to deal with a quality issues is never an enjoyable experience.
The prioritisation of features/stories etc in an agile project is the job of the customer so often it is unclear how to build in the non-functional features/stories into the project. A customer should be able to prioritise tasks related to the implementation of non-functional requirements if they are expressed in business value terms. If you can express these requirements in business value terms then the business should be able to priorities them. The important thing here is to capture the dependencies between the functional and the non-functional requirements so that the business realise the impact of developing a quality requirement in the later stages of the project.
Yes the role of the Architect in an Agile project is very different to waterfall projects and the people who succeed in a waterfall project won’t necessarily succeed in an Agile project. I think the key point in the article is that there is still a need for an Architect it just comes down to effectively executing the role within the principals defined in the Agile Manifesto.
