How do you know what to do?

The Architecture Process as far as Peer reviews and linkage to the Systems Development Life Cycle is well established. As Architects, you know when and where to interact with your Project Teams in a way that presents minimum risk to their delivery. (Yes, I know the things you find in the reviews risk their delivery, but these needed finding anyhow...)
What do you do with Issues coming from the review and who does them?
Well, during the Peer review you collect the Issues and hand them to the Project Manager. The Project Manager then has to manage the Issues, Solutions and Risk. Architects can help, sure, and can join the Project team to work on the Issues.
The Issues that arise from Peer Reviews are often good Architecture Issues or problems to solve, but they often don't amount to much in themselves; Architects need to find a way to get at the really big stuff.
What we need for real Architecture work is some strategy and a plan. That's where the other thread of the Architecture Process comes in.
It's all very well de-skilling Architects with fixed processes like Peer Review (they are, after all, just mechanisations of finding Components and asking the same old questions about them - e.g. My Architecture Qualities), but the real experienced Architects need to get in somewhere with the big stuff.
Experienced Architects need a Vision (or more than one...), they need some Principles from which to work, and they need some Objectives to work to (see my blogs on Strategy). We use these to drive our own Architecture Projects and Programs; the real work of Architecture. The method we use goes something like this:
- Define Vision, Principles and Objectives.
- Define your current state.
- Create/Devise your target Architecture.
- Identify opportunities and gaps.
- Develop Migration Options
- Implement.
And as always review and review again.
Well, I can hear you say, where are those opportunities and gaps? They're out there in your Business Projects; you've just got to look. If you've decided you need a Storage Area Network as part of your Disaster Recovery Strategy,then you need to look for Projects out there that have the requirements and take advantage. You need to take the first steps.
Of course, the first Project through the door is going to take a hit on time and money, but you could use your Architecture funding to make up the difference (Your Architecture work is funded, isn't it; I hope they take you seriously...). Don't forget to take out the difference when working out the Project's ROI, and remember to take the ROI on your own funding.
What we get when we put together these two threads of the Architecture Process are a Strategic process and a Business-as-Usual process, both interacting with the real world of delivery.

Will the last person out please pay the bill?

You need to have good cost control in an enterprise in order to put management of the costs back in the hands of the people that spend the money. Yes, obvious isn't it.
Allocation is the method; if you have a Server, you distribute the total costs of maintaining that server amongst the Business Applications that run on it. By allocation, again, you distribute the Costs of an Application amongst the people that use it. If I do a job for a group of people, I distribute my costs amongst the people I provide a service to.
The key thing here is that it is a Service methodology. Everything is related to everything else as a Service, and that Service must be paid for.
Cost Control done by allocation provides leverage; if a Server provides processing for 6 applications, and one of the applications manages to find cheaper processing, then the costs to the other five increase by around 20%, perhaps making them reconsider whether costs are cheaper on other Servers. Certainly as the number of applications drops towards 1 it's best not to be left carrying all the costs!
Unless you have this kind of allocated cost control it's going to be hard to determine if there is an economic advantage at all in moving to the bright shiny-new supposedly low-cost Servers. It helps Infrastructure people provide Server Consolidation by leveraging the Cost Model.
I do this kind of distributed Cost control amongst varying Service providers in what I call my Hydra model. Where I can relate People, Applications, Servers, Technologies, and Services under a common Service model. This Hydra model lends itself to Costs, Risks Service Level Agreements, and Impact Analaysis all under the same scheme.
Cost Allocation done by this Service Model is very powerful and enabling, producing a dynamic environment for change.
I do remember during 1998/1999 when we were doing Y2K remediation that we looked at an Application that was used by only three groups of Business users. We were charging them $100k a year to maintain the Application as their part of the costs. Well, we decided that to remediate for Y2k was going to costs a few million dollars, and looked for alternative solutions. We successfully found another solution that worked for two of the groups, but the last group refused to participate in requirements citing lack of time.
Well, we presented them with the multi-million bill as the only remaining users of the Application, and guess what, it did the trick and they moved, and fast!
It has to be done this way, otherwise nothing's ever going to move, nothing's ever going to be turned off or retired.
So, will the last person out please pay the bill?

What's your strategy for systems?

Another little gem from the world of Enterprise Architecture, this time I'm trying to figure out, during an Architecture Review, whether the team in front of me are on the right track...
Have we got to have a Strategy for Systems then? Well I guess if you have only one System doing Order Processing then I guess that you've already reached your nirvana as far as that functionality is concerned. The rest of us out here in the big corporations are having to cope with having 6 different Order Processing Systems, and to cap it all, none of them are "desired state".
How do we know where we are with our Systems and their functionality? Well we've put all our Applications into an Inventory like everyone else. Well you have haven't you? Then we've entered all the top Business Functions or Processes (Processes are best) and mapped those to our Applications. A nice little heat map shows where you've got trouble.
There's no doubt about it, one System doing Order Processing is a heck of a lot better than six. It's better on economy, it's better on risk and it's easier to manage, oh, and needs fewer people. There's only one state a little better, that's having two according to some people; two breeds healthy competition, and is safer for your corporation. Well go for one or two but not six.
To find out your "desired state" you're going to have to get all your users to decide on which system offers them the best deal, that is, the best functionality with the best non-functional qualities (There I've got that in again), at optimum cost.
Better here that you find one of the six Systems to base Desired state on since if you do what I've seen sooooo many corporations go and do, and built a brand-spanking new number seven system, I don't think you're getting the idea, the light at the end of the tunnels getting dimmer.
When you've got your desired state System highlighted, figure out how you're going to get onto it from where you are now. In we come with EAI tools to switch out the data flows from old to new and back to old again for reconciliation, and bit by bit we get onto the new one.
Now, don't forget to turn off the old System; make it a success factor of your new system project, that way you haven't succeeded until the old system has been completely replaced by the new system.
And please don't forget that if you aren't going to convert all the transaction history to the new system, then make sure that all the retained data is accessible and readable using common, everyday tools. You don't want to have rejuventate the old system to read the old data, since all the old system people have long since gone......
There is a school of thought that says that we shouldn't create any systems without turning off at least one old system, try pondering that one..

If it's not reliable it's not available....

I don't like to go on to much about semantics, we have enough difficulties with them, particularly in our industry. So that we're all talking the same language it's necessary to define the terms and then try to put them together in all kinds of wonderful groupings and relationships to provide a little more meaning.
Hey, I got some great feedback from Stephen and Scott about Reliability, if you didn't spot it look back at my Blog here. Stephen mentioned that he seperates Availability from Reliability, I do too, but it's a question of how we use the words.
Personally, I like to think of Availability as one grand Category, and I think the major players in the Industry do too (The "CIA" - Confidentiality, Integrity, and Availability). I then like to break these Categories down even further, and in the case of Availability I chose to break it down into it's parts. It's also very important to decide on what we're describing here, in my case I think about a Software Component. Then we talk about:
(Availability at the) Interface (Bandwidth, latency, protocol)
(Availability in terms of) Performance
(Availability in terms of) Service Window (Hours, Reliability, Recoverability, Supportability)
and
(Availability in terms of future) Scalability
You will see here that I put Reliability into the sub-Category of Service Window, and I guess that many people would see an issue with that. But I like it there, but if you feel strongly enough, tell me about it and I'll see if I can see your side and perhaps change my mind.
You see what's happened is that I am not concerning myself with the Reliability of the Component outside of the declared Service Window for the Component, since I don't care, I'm home in bed. It doesn't form part of the Requirements for the Component.
During the declared Service Window, of course, it affects availability during the window, and in combination with Recovering the Component once it goes wrong, and figuring out using Supportability features why it went wrong, we get an overall view of how well this piece of the overall Architecture meets it's (non-functional) requirements.
I may be wrong, and probably am, but perhaps we all need some help with definition, a Dictionary, a Thesaurus, a Toxonomy, an Ontology, because despite us all understanding the words, we all need some help in organising them together into meaningful phrases

You are the weakest link, Goodbye!

I was thinking about reliability a few days ago. Regular readers of this blog will remember that I've talked about this before under Availability. I think that we all realise that a System is only as reliable as its least reliable component....
At first sight 99% reliability seems pretty good, I just wish my Heating Boiler was that good! Truth is that 99% is awful. If you require your System to be available for 8 business hours a day for 365 days a year, then that 99% is going to give you a downtime of 29 hours. Nice if all the unreliability is during the other 16 hours a day, but it never is...
Now 29 hours is a lot in a year, but this figure hides a lot. Is this one downtime of 29 hours or is it 5,220 failures for 20 seconds a time, with 5,220 re-boots and recoveries?
I guess that is why we use Mean Time Between Failure (MTBF) rather than Availability %, which tells us much more about how long we have the system doing useful work before it fails again.
Everytime our System fails, we're also going to have Integrity problems, since there is some kind of a likelihood that there is a transaction in flight at the time of failure. The more Reliability failures, the more Integrity failures; these two Architecture Qualities are correlated. I think that I'm going to have to think about how many more of these correlations there are...
How about decreasing Bandwidth availability causing protocol timeouts, and these timeouts causing message loss or duplication? And of course repeated messages causes Latency, bad Performance.
If we could find measures for all the Architectural Qualities, and all the correlations between them, then maybe we could finally find that great nirvana, a measure of an Architecture's overall goodness?
I don't know, but I think I'll try.

Ivory Towers and getting real

My last blog (seems a long while now) reflected on the idea that Architects need to get out in the field working on projects rather than being centralised Architecture groups. Well, this is how it works...
I think we've all gone past that stage where we think we need large, centralised Architecture groups that have gained notoriety as "Ivory Towers" (where did that come from?). In times gone by (hah! you know they're still there) these groups were usually the first to go when the cuts came.
These days we have to get much closer to the ground where real delivery is taking place, where the real action is.
What we need here is federation; that is, we devolve power to the Architects and Designers out there in the various organisations and wrap a process around them to make sure they're performing to expectation.
So, we go out there and ask the organisations who their Architect is; preferably someone at the right hand of the Senior Technology Manager and bring that person into the fold of the Architecture steering group; the "inner circle". The Architect is pleased, of course, honoured even, but still has local power and the chance to make a difference at the corporate level. It's amazing what a new title and a new circle of friends can do...
But, for the "core" Architects, we need to say how the system works by building an Architecture Process. A process says what you should do, where you should interact, how you should work with reference standards, and how you are to use your peers in Peer Reviews (i.e. you must use your peers).
They've got a process and you have a way of measuring them (yes, I've said it again as in earlier blogs, I don't do, or ask anyone else to do, something that can't be measured, and you don't ask them to do it unless you've figured out how to measure!).
They bring requirements (maybe from Peer Reviews) back to the core group, so that the central group can have real work on real standards (after all centralised saves money), and these standards are pushed right back into the Peer Reviews, making the circle.
And you have many lively debates with these Architects and the (minority) core Architects determining direction. Two things that also help here; a strong sensible thought leader in the chair, and leave the rest to team dynamics (that is, the feature of TD that makes everyone want to agree) and lo and behold, we have democracy in action (except you don't know you're being manipulated, sorry no, that is just like democracy!)
What's the golden ratio of field Architects to core Architects? Probably 7:1 (why is this always the magic number 7)

Peer Reviews – Making them stick

It's all very well saying that you should perform Architectural Reviews on all your projects, but it's another story actually getting them to happen. Ways to promote, encourage, and downright bully project teams are required.
Everyone agrees that Peer reviews are a good thing, but it's amazing just how difficult it is to get a project team to "submit" to a review. They think you're interfering, they think you're going to change things, and they think that you're going to delay the project. Well that's two out of three right then...
Whether it delays the project or not, it's got to be right, and it doesn't matter whether the project team think they're delivering business value according to the requirements they have in front of them, they haven't got all the cards in front of them; the Enterprise Architect's have the rest.
Enterprise Architecture is all about (oops, sorry don't want to stir up any more hornet's nests), delivering IT Architectures that are Business-Aligned. Business Alignment is deep, it covers Goals, Ambitions and Directions (or some other semantic variants). EAs take this information from our businesses and design future-state architectures from it, and after agreeing it with the businesses, they expect us to police it for them. It's an overarching concept that transcends individual projects. (OK, off the soapbox...)
So, how do we make them happen despite the ducking and diving from project teams?
1. Build the reviews into the SDLC (Puleeeeez, I hope you have one...). Get reviews into the Initial and Design Phases. The Initial one in some ways is the more important since you can set the scene here before the designers have got themselves into positions that they want to defend - it sets early expectations.
2. Make it an Audit/Compliance item. Good Architectures reduce Operational Risk and OR is a business-killer.
3. Make sure that you have appropriate reviews. Come into Development projects not maintenance projects. Set a dollar level above which you are interested, let the small stuff go.
This is the one I like the most...
4. Build an Architecture Organisation that covers the entire Enterprise. Get people on the ground inside the project teams, give the existing architect/designers a grand title and make them network into the central Architecture group. They will bring the projects to you, and in return, they will help you develop a practical Architecture process.
5. Recognise Architecture for the value it gives, and make sure that recognition comes from the top of the organisation. Then you can name-drop...
And don't, please don't, go on about technologies. Technical people will talk all day about particular technologies and never agree; don't center the review around that stuff.
Look back at all my blogs and try to find one that argues about technologies, I don't think you'll find one. I think I'm an Enterprise Architect, and in that, I don't think technology is the be all and end all.
Enterprise Architects should use the reviews to further:
System Strategy
Business Aligned IT
Operational Risk reduction
So, if you do drift into a technical argument, make sure that you're doing it for one of the above.
And in a further blog, I'm going to tell you how I think you measure these things.

Knowing when to add your two cents

Attention to Architecture offers a great deal to the success of a technology project (as long as you know what success is - see "Did we do well"), you just have to know when and where to engage...
Its all very well being the centre of the known Universe as far as technology strategy is concerned, but you need to be aware that the Universe doesn't turn around you, it turns around projects.
So what can you do to add value to these projects? Well I think it's fair to say that as a minimum you engage and as a maximum, well let's see what the mechanism for engagement is...
1. All projects should be run based on a Systems Development LifeCycle, no matter whether they are multi-million dollar megaliths, or agile, iterative itsy-bitsy projects. No matter how many stages are in your particular SDLC, as a minimum you (i) Figure out what you are doing (next) (ii) Figure out a solution for doing it and (iii) You do it.
2. Architects should work in a formal way adhering to a formal method, usually along the lines of an Architecture Process, and that Process almost always dictates the method as formal review.
So, when is the right time for review? Well, every Architect that I've polled prefers at least one, and at most three times during the lifetime of a project. These times are (i) Initiation (ii) Design and (iii) Post-Project. The actual reviews that you carry out depends largely on the size, complexity and risk of the project, and any project that dips below the radar screen on any of these three points doesn't qualify at all as a project (after all, you can't possibly engage for every little change going on in a large Enterprise).
Initiation reviews are mainly about direction for the project, and act as a way of communicating to all concerned what the scope of the project is, and declaring what the agreed strategy is. Post-Project reviews are about learning from the process by analysing what issues got in the way of architecture and project success and inserting feedback into the process for later improvement.
The minimum review time for any project worth its salt is a Design time; this is the time where we have a proposed solution complete together with business needs signed-off, a few nice pictures, a selection of technologies and an estimate of total solution with reasonable accuracy in terms of dollars. At this point the business knows what it's return is, and we have the technology costs that offset those wonderful rosy numbers.
Design time is where we stop and do the reviews most often. Architects and other Subject Matter Experts gather around a table to hear whats proposed and debate technology selection, issues and risks as only they know how. You then summarise all the issues you have with the project (you shouldn't stop the review unless you've found something, even if it's criticism of the coffee), and make them action points on the Project Manager to close before proceeding.
Of course, designers and developers don't like this part, they always believe they have the only solution possible, the best technologies to use, and the best methods. Working in interation mode without a formal review, the arguments run and run and ulitmately endanger the project, but I find that it's best that we agree that we don't leave the room until we've debated the issues and come up with an agreed way forward.
One review, one set of issues to manage and no further debate, and as long as everyone agrees up-front these terms of engagement the whole process is better for all concerned.
The alternative is having one of those Architects poking his nose around the corner every few minutes, sometimes with a different story, and always forgetting what things he talked about last time. Less disruption, less risk, and one story to tell; that's healthier I think you'll agree.