Capping IT Off › The perfect business application

Capping IT Off

Capping IT Off

The perfect business application

13 Comments
Category : Custom Software Development

Cost is becoming an ever increasing player on the market. Total cost, not just project cost. Time-to-market is good, but time-in-market is better, so to say In the end, there are questions that need to be answered. 70% of those questions are asked after the go-live of a project, not during A project might be successful but maintenance might turn out to be a disaster (or anything in that grey area in between). Fill in the blanks for a project and run, a build and test, a design and build For the 30% of the questions that get asked during the project, the same principle applies: the farther down the chain these get asked, the more costly they are So, how can costs be minimized? Well, just by making an existing application perfect, or by creating a perfect application What makes an application perfect? Great ease-of-use, splendid user interaction, and availability That is achieved by a humane (sic) approach, a fault-proof approach, and a resilient approach. The word approach is used, because there are several phases in which the timeline between beginning and end of an application can be divided. Design, build, test, run, use, maintain. The perfect application should be perfect during all those phases

  • The humane approach is achieved by approaching the application as if it were our own, used only by ourselves
  • The fault-proof approach is achieved by approaching the application as if it were everyone else's
  • The resilient approach is achieved by approaching the application as if it were everyone's application, used everywhere
A perfect application can be measured from the end, backwards to the beginning
  • Is it hard to maintain? Then the technical documentation is not complete enough, or the code is not legible enough. It is not fault-proof for the maintenance phase
  • Is it hard to use? Then the presentation is not intuitive enough, at least not for the users that have to work with it. It is not humane for the use phase
  • Is it hard to run? Then the technical operation is not easy enough, or too costly. It is not humane nor fault-proof nor resilient for the run phase
  • Is it hard to test? Then the functional design is not clear enough, or the technical design is way off to the functional design. It is not fault-proof for the test phase
  • Is it hard to build? Then the technical design is not clear enough, or the functional design not clear enough in order to draw a technical design. It is not fault-proof for the build phase
  • Is it hard to design? Then the business specifications are not clear enough. It is not fault-proof for the design phase
Everything starts with the business specifications. They draw the lines for the business application that serves a business goal It seems that the overall answer is easy: every question needs an elaborate and documented answer as soon as possible, and it all starts with the business design
  • For every business rule, there is a business exception. Embed that into the business specifications, so the scope is clear
  • In the functional design: for every business rule, there is a functional exception, and an appropriate user interaction message. Embed that into the functional design
  • In the technical design: for every functional rule, there is a technical exception, and an appropriate user interaction message. Embed that into the technical design
  • In the build: for every technical rule, there is a technical exception, and an appropriate user interaction message. Embed that into the build
Is this rocket science? Certainly not. Are details of this overlooked every now and then? They sure are Is this a handy checklist? I sure hope so.

Martijn Linssen is Enterprise Integration Architect within Capgemini. You can follow him via Twitter or join him on LinkedIn

About the author

M. Linssen
M. Linssen
View all my posts
13 Comments Leave a comment
gasharma:
gasharma's picture
I agree with you, specially when you say "70% of those questions are asked after the go-live of a project, not during project..."
Many projects build technical debt to remain within the fixed cost of project execution. But technical debt then manifest during later stages of application lifecycle and with compounded interest.
Arun Zachariah:
Possibly true, but for it to be the case you must also need the perfect business - one which is completely tuned into its operating environment (which theoretically should also be completely stable) with no fear of competition. Seeing as there aren't any perfect businesses, surely it stands to reason that logically there cannot be a perfect business application? The less a business needs to change, the less it needs its automated parts to change. The more a business needs to change, the more change is needed in its systems.
If a business needs to change to adapt to its environment, then the longer the systems take to change, the more likely the business is to suffer a loss of advantage.
Unfortunately as writing a complete set of business rules, coupled with a complete set of functional specifications etc can take an inordinate amount of time then by the time the business application is delivered, the business need might have changed sufficiently to make the perfect business application less than perfect.
I don't have the perfect answer (and I'm not convinced that it exists) but I suspect there are a lot of "acceptable" answers, but that's down to compromise and tradeoffs.
Martijn Linssen:
Hi Gaurav, agreed!
Hi Arun, why would you need a perfect business for this to be the case?
And if your business need has sufficiently changed to make the application less perfect, what would you do then?
Martijn Linssen:
Hi Gaurav, agreed. And looking at the future, that 70% is going to be a busier place than we're used to
Hi Arun, why would you need a perfect business for this to be the case?
And if your business need has sufficiently changed to make the application less perfect, what would you do next then?
Arun Zachariah:
Hi Martijn
Without a perfect business (in the crude way I tried to define it in the last post) then I'm not sure how you can define "the perfect business application". Not only will it need to cater for whatever it is automating in the business today, but it will also need to cater for all the possible future states that the business will need that aspect automated. And by cater I don't mean it must be able to deliver that capability, but must be evolvable into the necessary state (if that makes sense). That is rarely a cheap objective to meet and if you've got to worry about an unknown set of future states then there's the risk of "analysis paralysis".
As soon as the business reaches a state that means that it will cost the business more (money/effort/time/any other metric the business thinks is important) to transform the business application (in its maintenance state) into what is needed compared with the cost of starting from a blank sheet of paper, then by definition that business application is not perfect - I think the word "perfection" is academic, hence me saying that there are a lot of acceptables.
On the other hand, if it is quicker/cheaper/easier/any other term the business thinks is important, to modify the perfect business application to meet the changing business conditions (or at least being able to track the conditions) then you could argue that that business application is still perfect (although I prefer the term "acceptable" ;-) ).
Martijn Linssen:
Arun, you're perfectly right...
The business will never be perfect, it's much like the weather: globally foreseeable but highly unpredictable locally. Although there's no need to prepare for sun burns on the North Pole. Then again, if the business can't get any better, musn't the phylosophical conclusion be that it's perfect already?
Cost is, yet again, the driver. You should be able to put a bigger engine in your car, but if you want a limo then you better buy a new one. You're not going to pay for a harmonica-like car that can be turned into a limo at will.
It's all about bandwidth, and perfect means perfect all the way through for the intended life-span
Maybe it's best explained by comparing it to a marathon and a triathlon: some projects seem to run a marathon while dropping dead just over the finish-line. What we need are projects that first swim 3.8 km, then bicycle 180 km, and after that still have enough energy and breath left to run a marathon
Martijn Linssen:
In my last post, in the last paragraph, it should have said "applications" in stead of "projects". That first finish-line is the go-live of the project initially delivering the application
David Gale:
There is another way: <a href="http://www.youtube.com/watch?v=GYr-Eo5-ntE" rel="nofollow">http://www.youtube.com/watch?v=GYr-Eo5-ntE</a>
David Gale:
So, the question would have to be, "For how long is the perfect application, perfect?"
If you didn't 'get it' yet, it's about flexibility and the ability to change processes and application functionality in response to changing business needs.
What's required is a combination of service and federated oriented architectures to deliver a sustainable, flexible and responsive environment.
Martijn Linssen:
Thank you David!
Impressive video, and I absolutely agree with your question. I think that period is getting shorter every day
It's not about running a marathon and dropping dead at the project go-live finishline, covering only 30% of an application lifetime
It's indeed about flexibility and changeability, for what we call Process-on-the-fly in our Technovision (http://www.capgemini.com/services/technology-services/technovision/), and covering the entire track
Interesting comment about services, maybe there even won't be any such thing as an application in 10 years from now? Will we call them "federations" instead?
David Gale:
Thanks, Martin. Check out some of the other SITFO.org videos from the same link as above. The federated Customer Service Information System (CSIS) demonstrates how CRM becomes just a component of a federated architecture that can deliver a 360 degree view of the customer and their relationships with multiple organisations. TADAG (www.TADAG.com) enables identity management and records management in a way that supports the federated architecture, although part of it has already been pinched to resurface as OpenID.
Regards to Graham Colclough, if he's still at Cap...
Puneesh Lamba:
I agree with most of the informaiton in the post but there are more ways to reduce cost of an enterprise IT project and I saw some of the good ones discussed at <a href="http://tinyurl.com/mrr8rw" rel="nofollow">http://tinyurl.com/mrr8rw</a>
Above all, if the zeal and intent is there, I think saving cost of an IT project becomes much easier.
Martijn Linssen:
Thank you Puneesh. You say lots of interesting things on the website you mention. SCM and ERP belong to the most challenging and complex engagements in ICT
You have some very practical bullet points on saving cost on projects. I especially like the "Exams are still the best way to gauge a student's performance"
I don't like to save cost just on projects alone, though. I think cost-squeezing on projects leads to exploding costs after the go-live, when you have to "answer all those questions" that were 'succesfully' managed off the project budget
We have to consider the entire application in its full lifespan, and how it will be able to contribute to the business, now, then and in the far future. A good example you give is to not over-customize a package, as that will undeed unleash a (very costly) monster

Leave a comment

Your email address will not be published. Required fields are marked *.