The weekly change meeting came and went. Unfortunately our developers one-page udpate to the company's website didn't make the agenda since they ran out of time to review and approve the change. But it made next weeks meeting.....

The change review board didn't think the change warranted much consideration which was a relief for the developer. They scheduled the change for the weekend after next since this weekend they had some urgent updates to do and the risk of so much change was too great for this additional update.........

And then the problems started. The one-page update didn't work when the deveoper checked out the production site after the change (he came in all weekend to check the change went in correctly), it didn't work due to some security problem. Apparently the updates of last weekend were security patches, and somehow they were affecting his page.

The change was backed-out.

Work Done to date: 55 man days. Elapsed Time: 6.5 Months

Almost done now, the end is in sight. Our intrepid developer has spent nearly five months now trying to make a one-page delivery to the company's website.

He has a two-page form from the Systems Implementation team, however, and it seems to be asking for stuff he hasn't got.

Well, he was asked for technology details and disk space, this was no problem.

Two Directors signatures were a little of a problem though, because his boss had just left for a weeks vacation break, and two other Directors seemed to be on a two day offsite. The only remaining Director didn't know him, didn't know what he does, and consequently refused to sign anything he didn't understand. One weeks delay.

The Security assessment for the website had expired, of course, and due to new rules introduced, no change was to happen on any website, for any reason, without a current assessment. He had to be really nice to the corporate security people, call in a few favours, and not an inconsequential number of beers, to get them to talk to him at all. Three days before they could fit him in, and no, they didn't want him to tell them about it beforehand.

The Build Permit for the application was a problem though; a huge problem. When the application was developed and installed, there wasn't such a thing. "Your Director sign up to it" was what they said, "there are no exceptions". Legacy applications have to be reviewed at the very first change after the rules were introduced; rules are rules. "We meet monthly to consider permits" said the great administrator Architect in the sky. "Oh, and we had one last week, but we could just about fit you in next month". "Here's a nice and handy checklist of the documents that you should send to us beforehand, let's say, by the end of next week?"

Three more weeks delay......

As for the Ethical Hack certification, yes, got it. Hah, just got to find the email............

And as for internal audit, not a problem. They signed off once all of the above was produced, except they too were on vacation right at the end causing a few more days delay.

The developer just had to wait for the weeky Change meeting to get the go-ahead for the change......

Work Done to date: 50 man days. Elapsed Time: 5.75 Months

So, as an aside to my little story about the developer's frustration, I was thinking about how we could improve on the efficiency of the development model, to get to a better place...

If our developer doesn't want to do all these different jobs on the way to productionising his code, the jobs such as Project Manager, Business Analyst, Architect, Designer, Auditor, Administrator etc, then we need to specialise and stream the work.

Imagine for a moment, a world where the developer does his one-pager for the website in one day, but does 200 of them a year, a world where the Designer designs solutions for 40 projects a year, a world where the Business Analyst writes up functional specfications for 20 projects a year, and a world where an administrator maintains security compliance documents for 2000 webservers twice a year, a world where Change Administrators update, upgrade and install applications every single night?

Do you think that this environment would offer efficiency? Yes, probably.....

Do you think that this environment would offer interest, progression, advancement?

How do we balance the need for efficiency with the need to advance ourselves?

Do you think that variety IS the spice of life?

Our frustrated developer has been waiting over four months now to get his one-pager onto the Company's website, and he still can't see the light at end of the tunnel, if the light actually exists at all (In religious terms he's moved from firm believer into agnostic)

Today he received an email with an enormous form attached that provides details to the Systems implementation team so that they can put his one-pager into production.

They wanted to know:

1. Technologies involved and versions required. (He replied ASP.NET, Javascript, HTML, CSS and access to a database containing some reference information).

2. Disk space required

3. Signatures from two Directors.

4. A copy of the most recent Security Assessment for the overall Application (valid within the last six months).

5. A copy of the Build Permit for the Application from the central Architecture function.

6. A copy of the most recent Ethical Hack for the website (valid within the last 12 months)

7. A sign-off and go-ahead from Internal Audit on the change.

Work Done: 40 man days. Elapsed Time: 4.75 Months

Our brave and exceedingly patient developer has been trying to put his new Internet Page on the Company's Website for 4 months now, and finally last week he got to write the code. He did it, just as he said he would, all complete and tested in one day by his own fair hand on his desktop machine. He's ready to go, let's see it up on the site then.......

He rings the Service Delivery Team, the last bastion of defense of the Data Centre and asks to get his code "promoted" onto the Production System.

"What's that then?"

"It's a new contact page for the website."

"Is it a patch or some kind of fix?"

"Nope, it's an enhancement."

(Alarm bells are ringing.......)

"Well, you have to go through the approved procedure for that, and we'll need more information, I'll send you a form. Click."

Our intrepid developer slumps back in his seat and awaits the mail...

Finally, our very patient developer has got the go-ahead from the Architect to cut the code. This is the culmination of 3.5 months of patient waiting, discussing and analysing and a veritable mountain of documentation.

His original estimate of one days development work is about to happen, and he's raring to go....

So, it's a further two weeks while he fixes the production problem before he's given leave to carry out his oh-so-valueable enhancement.

Post Development Work Done: 35 man days. Elapsed Time: 4 Months

A recent report by Symantec highlighted that within two years 66% of our Data Centres are going to run out of space. Whilst I would readily admit that it is good news for the IT Industry as a whole that that our services are in increasing demand, it's bad news in that despite the enormous strides we've made in technology, we don't seem to be keeping pace with demand.

What's going wrong? Well I think it's simple, we need faster machines with lower heat and energy usage.

AND......I'd also like to thow in the fact that we need better management of what we've got.

Why do I say that we need better management? It's because it's also a fact that on average our CPU utilisations of these machines across a typical day is 15%. Peak demand means that we need 100% of CPU utilisation at certain times of course, but on average, a typical machine is taking up the space that 7 machines should be able to fit in.

How do we do this? With virtualisation and more centralisation. I suggest that if we concentrate in one Global Data Centre we should be able to "follow the sun" for working-day usage across the world. Virtualisation will help in better average utilisation of what we've got.

What do you think? Any better ideas?

The Definition phase of a Systems Development Life Cycle, sometimes called the Analysis phase, is really a requirements analysis, a phase where we can really understand what we are trying to do for our business customer.

Yes, I know that we already known what we need to do, after all our developer has talked to the business customer and written it down on his notepad. And, that Business Analyst that they kidnapped from the other project has already written it down in the Initiation Document.

And, the business customer has said yes, he'll pay, even though it's taken him four weeks to tell us (apparently the boss was travelling abroad and the investment meeting was cancelled, and they only hold it once every two weeks, and we'd just missed one...).

Can we get on with it then?

Er, no, let's really get down to detail. First off, we need to write down step by step what is required to happen, and we need to assess whether the right data is in fact in the place that we hoped to find it, and apparently the compliance has told us we need to have technology controls in place for security because apparently the data we want to show should only be viewed by the Front Office and some people from the Back Office as long as they are in the European Union. Damn......

So we spend time detailing rather more exactly the work to be done and "enhance" our cost projection. I say "enhance" when really I mean increase dramatically. Actually on the plus side we're also going to get better in estimating here becuase we'll move our Initiation Cost projection from what we would call a "Level 0" with 75% variance (it could increase by 75%), to a "Level 1" estimate (which could increase by only 30%).

Well that's great, isn't it, we've really narrowed down the cost projections to something more workable, trouble is the actual cost projection has doubled!

Anyway, we'll go back to the business customer with our new functional specification and new cost projection (i.e. double) and ask for signoff to go ahead. Well, of course our business customer doesn't go back to the boss with the new costs because he doesn't want his little project to be canned.

He shrugs, nods, and we're on our way.

Work Done: 30 man days. Elapsed Time: 2.5 Months.

So, as I said in my last blog, I'd like to look at all the things that make our 1 day development task turn into a 1 year deployment project. Today I'll turn my attention to the first step in the System Development Lifecycle, that of Initiation.

Some people would say that Initiation is where we have identified a need for technology to solve a business problem. I'd say rather that everything is a need, but it's really a question of business priority.

So, the developer has some feedback from the business users where they stated the need for a few features in their system to make their jobs easier and more efficient. But the developer can't of course just do it. We need someone to put together a business case, a rationale, for why it should be done.

This someone has to be both Business Analyst (to understand the problem) and a Project Manager (to get organised around the potential project).

So, we wait for someone to help us, someone who can be assigned to follow the process; someone who can produce the necessary documentation and follow the company's standard methodology for getting work done.

So, we put together a document stating what we believe needs doing, perhaps some alternatives, a statement around alignment with strategy, a summary of the anticipated costs, a statement of the business benefits, a formal statement of the anticipated return on investment (ROI), and an indication

of when the work can possibly be done.

And you would think that would be the signal to start work, after all, the business case is clearly there and there is a definite need. No, of course it's not as simple as that, as I've explained to anyone that will listen, just because there is a need it does not mean it will be done, there are many projects competing for business money and the pot is not bottomless.

The next step is Business Prioritisation, which is something outside of our SDLC, where the business look at all the work offered, all the projects and costs, and decide on the relative priority against their budget.

Well, that wasn't so bad was it? The developer hasn't been too busy here, but has already spent 2 man days explaining to the Business Analyst the work that needs doing and the estimate for development and deployment. The Business Analyst has spent 10 man days working the process, documenting the proposition and discussing it with the business. Finally the proposition has been left with the business for their next prioritisation meeting.

One of the things I have to do in Enterprise Architecture, and have been called to do a number of times, is set up a process for Architecture in an organisation.

Generally, in large corporations, EA has much more to do with how you do things rather on what you do. It's not good to be good at determining Strategy, or good at J2EE Architectures, or Security; it's very good if you know how to go about doing things if you want to get along in this game. If you want to be the Chief Architect or Head of Architecture or other head honcho, you've primarily got to know how to get organised.

EA processes touch many areas in IT in the Systems Development LifeCycle, in IT Strategy setting and monitoring, in Investment Reviews, and in Audit and Compliance reviews.

And they introduce some of their own around defining standard components, standard technologies, and design reviews.....

The thing is, these kinds of processes standardise EA itself, they are the processes that define EA.

Gone are the times when "Technical" Architects stirred up trouble, got under your skin, got in the way of development and generally make a nuisance of themselves. Today we are much more process-aligned, coming in at the right time, making our points, and shrinking back into the background until review time.

Over the last few years we've been developing custom processes to support these activities and been reasonably successful. Today, though, I've noticed with such things as TOGAF 8, these processes are becoming more prescriptive, standardised and mature. It's good stuff, but you can take as much or as little as you like. It doesn't tell you about diagrams, and it doesn't tell you about technology; it tells you what to do.