Have you ever been in a meeting where you ask ‘how’ something works and you only get an answer about what it does? Or .. you get an answer that is so detailed that you make a mental note never to invite the respondent to the meeting because they are “too low level”. Or .. you ask why a component works a certain way and the answer is ‘ask the architect’ (hmm .. I thought you were the architect?)
It almost seems that you get a different answer depending on WHO you ask – even within the same team! This is particularly bad in the IT architecture space because – well – everyone wants to be an architect. I personally remember the feeling of absolute glee when after approx 5 years of waiting and 2 job changes, I officially landed a role where I was ‘the architect’. You would not believe what sort of other titles people will come up with just to avoid calling you an architect (at least that’s what it felt like at the time!).
Ok – back to the point of the post. I thought it might be an idea to try and express the different types of architect roles (WHO) in your typical big-IT environment and how their work interrelates in a complex web of why,what and how. If nothing else, it’ll help me remember who what sort of answer to expect when I ask the business architect ‘how’ a given component we are building affects the business user..
The business architect helps the business to define a suitable business process to achieve a given outcome (BUSINESS WHY) and out of this, what technology needs to do in order to support the business. At this stage, all we have is a ‘BUSINESS HOW’ that may have some technology components.
If a process involves technology, the solution architect is given the business process definition and any related material as input/justification (the SOLUTION WHY) and asked to come up with a solution. They start from the technology touchpoints identified in the BUSINESS HOW, and in conjunction with the business architect and/or business analysts gathers further details around how the business process will really interact with technology to achieve this outcome. At this stage, we have progressed our understanding to a ‘SOLUTION WHAT’ (ie what is the solution really meant to do, precisely defined in reasonably measurable tech-friendly terms).
next the solution architect works with various specialists (ok, “technical architects”) to devise a workable end to end solution to meet the objective. At this stage they have defined a ‘SOLUTION HOW’ at minimum, and if they have really taken the time to talk to the people responsible for all the components, they may also have specified what each components is responsible for – i.e. ‘COMPONENT WHAT’s. Interaction definitions within the solution design provide justification these capabilities, so the solution design also serves the role of the ‘COMPONENT WHY’.
finally in order to actually build out the components, the specialists need to work out ‘HOW’ they are going to make their component do what the solution architect has come up with. This gets captured in detailed specs which are the ‘COMPONENT HOW’s. These of course form the builder’s WHY, based on which they will BUILD WHAT THEY ARE MEANT TO!
across all of this discussion, we haven’t even touched on the data. Data is the 4th dimension to all of this – ‘WHERE’. At solution level we talk about where data is mastered and where it is moved to and from as part of interactions. At component level we talk about where a data item can be found in transit (integration) or at rest (database, filesystem etc).
WHEN is always yesterday – no need to discuss this point.
Note that in smaller organisations, some architecs will wear multiple if not all of these hats. It is however important to ensure that the different perspecitves of a solution are understood and addressed adequately.
For the non-architects out there who have to interact with IT’s most trusted profession, hopefully this gives you a view of the different perspectives that people labelled as “architects” might be viewing things from – if nothing else it will help you understand why they say they are in sync but are constantly arguing!
PS – having written this I think I’ll take another look at the Zachman framework – maybe the penny has finally dropped on what he’s on about 🙂
After a few years of pushing into enterprise architecture I have taken a break and gone back to a solution/delivery focussed role. This was a move made with some trepidation but 5-6 weeks in, I have to say that it is good to be back in solution mode, working to create a practical rendition of someone else’s enterprise architecture vision. What better way to inject some reality into the Powerpoint-coloured glasses 🙂 Interestingly, even though I am officially “just” a delivery guy now, quite a few of the things I am having to do will have enterprise reach if successful. So watch this space for insights from “the other side”. Topics may include SOA in a COTS environment, data governance and possibly even some stuff on the middleware of the day (see my tag cloud for hints) if I manage to get close enough to it.
I’m very excited about the l-o-n-g-awaited launch of Glassfish 3.1, as it seems to have a very similar “shape” to WebLogic which is an app server I’ve been using for a long time. (“shape” = Admin server, managed servers, node manager, scriptable setup, good high availability, nice admin console etc etc).
Looking around on Glassfish.java.net I found this rather interesting white paper comparing it with Tomcat (hopefully it will be updated to reflect 3.1 capabilities such as clustering). One point of comparison was their “CGI” capabilities – apparently this is still an important feature for application servers! Check it out below:
I wonder which application server they used to make Avatar?
Seriously though, I will be checking out Glassfish 3.1 in detail albeit for more pedestrian goals like providing a robust and cost-effective “full service” appserver for my mission-critical apps. Sure I can embed ActiveMQ in Tomcat, but do I want to? Watch this space for my findings 🙂
Over the last year or so, I have been leading an SOA initiative which by all accounts has gone relatively well, with one downside. All the developers and architects will give it a qualified thumbs up (hopefully not just because it’s good resume fodder), but the business analysts and business owners of the applications that are enabled by our beautiful service catalog, have no appreciation of what the services are and how they affect them. The only exception from this is services that we expose to our customers as web services.
So how do we ‘take SOA to the business’ – and more importantly, why should we?
The recent release of TOGAF 9, which includes a chapter on SOA has made it clearer. Basically, we have been doing developer-led SOA (or for the sake of my ego, architect-led SOA), building little-S services that are important building blocks for the techies, but the business couldn’t care less about. Ironically, the highly resuseable services that the developers love are probably the ones that are least meaningful to the business (future post on this). In order to ‘take SOA to the business’, we need to think of the entire business as a set of capabilities that we provide to customers through a combination of people, process and technology. These capabilities are big-S services, and are recognisable elements of the business value chain (e.g. assessing a credit card application). Their work has a quantifiable real world effect on the bottom line (as opposed to a technical real world effect such a database table being updated), and similarly their SLAs on performance, availability etc. are traceable to a commitment to a real customer or other business stakeholder.
But wait, there’s more.
ITIL v3 gives us a service-centric framework for managing the lifecycle of IT services, i.e. capabilities provided by IT as the technology contribution to big-S services, and is already well established at the ‘lights-on’ end of the service lifecycle. In my opinion there is no reason why we couldn’t use ITIL as an overarching framework to manage the lifecycle of all big-S services, and then overlay whatever else we need at the lower-level to manage the lifecycle of the little-S services that contribute to a big-S service. As an examlpe, this is where we would see the intersection between the service registry/repository and the CMDB.