IT projects are in the IT domain, just like Marketing projects are in the Marketing domain. Makes sense right? No, it doesn’t.

When we take a look at IT projects, we need to understand the fact that the only right of existence is the fact that we support business processes. This means that we need to support and suffice the processes that make the business run, makes them tick. Any IT project is only a way to support a goal, we don’t make the goal, we don’t reach it, we just pass the right shot ahead.

The days that we thought that we understand the actual processes, problems and challenges the business is in, need to lay behind us. Think of it as: ‘we just don’t get it’. This isn’t a bad thing, it’s a good thing. We are good at IT, not at running the entire business. Yet we tend to pretend we are.

IT projects that mainly lay within the IT domain usually go bad, this is because the wrong people try to model and fix business problems and support business challenges. If we take out the responsibility out of the IT domain into the actual business problem owners domain, the right decisions can be made and progress is more eminent.

This strategic choice means we need to get focussed on what we do best: IT. And the business can focus on what they do best: business. This results in a way of working that is much more efficient and pragmatic. We can actually help the business to achieve their goals.

Last friday and saturday we, at Whitehorses, had our yearly DeveloperDerby. This beautiful and fun race for developers is for our developers, by our developers. This year we had an actual client case of one of our beloved clients, Ricoh. And this is where it all changed…

In previous years we developed an application for a fictional business problem. This year it was an actual problem and the client was there to help. Two Ricoh executives where available for questions, reviews and other interactions. Because the teams only got a minimum of information beforehand and they needed to deliver something that actually worked within two days, they where forced into agility. A beautiful process and very educational.

Using the moments with the clients, our four development teams got all the information that was needed. All teams where made agile because there was no information to be found, not on paper, not on the web, not by experience. We had a client case that was extremely challenging and the teams needed to show their creativity in order to really grasp and solve this problem, by adding value.

And value was found. Although, like everyone else, the client had a solution in mind, every team came up with a different way to solve the problem. By offering self service in a very accessible and fun way to the end clients of Ricoh, they would save money on sending personnel to their end users. Fun and pretty.

The Ricoh executives where taken trough the process by all our teams, they showed solutions and prototypes, talked about different ways of looking at the problem and got new insights in helping their client base. Managing relations and offering solutions to real live problems. In short: adding value.

In the end, a strange thing happened. Two of four teams where called winners. Both these teams interacted with the client on all occasions the had. Therefor had a lot of insight in what the client moved, what they would think would be sexy and attractive. Talking to them certainly helped understanding the complexity of that what really needed to be done and what was beneath it all.

Agility equals success.

If solutions are our business, why is it that there are often solutions implemented that aren’t really solutions at all? Or, at least, don’t actually solve a real and existing problem. It is strange that we all earn our money resolving challenges for business, yet we tend to stick with the familiar technology driven solutions. On the other hand, if we stick to real business situations and the challenges they face, we come up with solutions that will only work in a few situations.

Tech driven IT no longer has reason to survive. We tell ourselves this for a long time now, but we still do it. This is why: we just don’t get it. And we need to stop thinking that we get it. Business’ problems are for the business, we just need to facilitate how they can be solved.

Example: I heard, in a tech session, the following statement: ‘we use a business driven, instead of technology driven, approach. Now the customer can think in ways of business processes instead of screens in their applications and systems’. On my return question about what this actually solved, there was no answer. In my (humble) opinion, moving to SOA structures so the customer can move from ’screen-thinking’ towards ‘process-thinking’ about their systems, is just a solution, not the problem that is solved. Simply because thinking in screens in itself is not a problem. But it can have implications. There you go.

The first time I encountered Cloud Computing, which was a few years ago, I realized that this just might be the future of our business. But why? At first I couldn’t grasp it exactly. Whether we take a look at Software as a Service, SaaS, Platform as a Service, PaaS or simply hiring some computing power, I learned that five elements are essential within this part of our business.

1. Strategic. Every step into the wondrous world of the cloud has to be a strategic one. People tend to think of it as a scary choice, but the last few years it has taken a leap and therefor there are some more guarantees build in. Once an organization has made the choice for the Cloud, they have done it with some reasons. The following thoughts may lye beneath those choices(, but maybe there are more?) The strategic choice for the Cloud can be found within economical aspects as well as business strategic elements. Cloud computing might mean that the internal IT department of an organization might get smaller or even absence. It shows us that IT really has to be supportive of business processes. Cloud computing therefor only can exist if this is true.

2. Sustainable. While in the traditional business software world we like to think in orders of ‘maximum availability’ and ’software / hardware performance’ the essentials of cloud computing lye in ’shared services’. This means, that when we maintain the traditional view we need to make sure our hardware and software are able to handle the stress of the maximum load needed, sometimes even redundantly. This means at least two servers that have the computing power we, at the peaks of it’s use, need. Even if the application or systems running on it only need to run a few hours a day. With the shared computing powers of the cloud we can take advantage of the stress balance that we simply have because we all work on a different time-table. Business hours are not the same over the world. In this way we only consume that what we actually need.

3. Services and Standards. When we move towards the cloud we will need to force ourselves to work with standards. The service we will work with need to be based on these web standards if we want to take real advantage of them. A lot is said about standards, and this is, again, a strategic choice within an organization. Standards make sure we can ‘recycle’ and ‘reuse’ our software. When we take a look at what this means for cloud computing, we see that this is the only way to go. Future integration and migration will be a lot simpler and maintenance will get cheaper.

4. Money. As we know, it all starts with money. When we start using cloud computing there’s no need for a large injection of capital to get started. The capital expenditure (CAPEX) will get lower, however the operational expenditure (OPEX) will probably get higher. This means that there’s no need to invest initially in hardware (and sometimes software) costs. We only pay for what we use.

5. Scalable. The Cloud is more scalable than any traditional hardware / software implementation. This is because we share the services and therefor simply can add more power to the service we’re running. This scalability can be very attractive for organizations that have a traditional scalable market and work with variable workforces. Besides this, it might just be very attractive for startups, because the uncertainly of growth is something that’s not an issue anymore.

These are just my thoughts, are there any more elements that we should take account for?

Who wants to Live Forever? Great song. Not so great approach to Software Development though.

When we take a look at Software Development, you’ve probably noticed the situation that any app that has even been build, still is fully running today. At the beginning of the lifecycle of an application or system, we like to think how long the system might run. We develop an application that simply is designed to run for about four years or so, but the reality looks quite different: legacy applications that run for over ten years within an organization aren’t that weird or strange.

So, where’s the problem here? It’s simple: over the years we’ve learned a lot about user interaction, functionality and system integration. These wise lessons don’t apply to legacy systems and, if we keep on thinking ‘we already have this, why throw it away?’, nothing will change. And change, within every organization, is essential and adds most value. Business Processes get changed in order to support the system, instead of the other way around. And a lot of effort is put in maintenance of these systems.

Developing something that basically already exists is considered nonsense and pretty scary to most people. That we try to keep something running that should have been buried years ago doesn’t change anything about that emotion. So how can we change this?

Systems Integration, or Service Oriented Architectures might give us the solution over here. With these new insights, methods and technologies we just might be able to keep using the application that has been build ages ago and change it to meet the requirements we have today. Integrating systems and let user interaction play in a modern way, based on business processes, instead of standard functionality.

Although a solution can lay in SOA, I strongly believe that design is always cheaper than redesign. When we can design and develop a system from scratch, we can make choices that weren’t made in the original. Redesign, even with the capabilities of SOA, also means that we have to work around the boundaries the original legacy system gives us.

Besides that we still will have the large maintenance costs that come with (unsupported) legacy systems.

What do you think? Will we ever get rid of these legacy systems? Or are they just a given part of live?

This morning I did a great session for the Software Engineering department and its student at Fontys Hogeschool in Venlo. It was a great and interactive session.

Lots of student already did some actual software development projects and had a clear view on what the different methods and methodic are in our line of business. And this is an awesome result. During the presentation the students showed a very proactive attitude and really wanted to learn how project development ‘in die praktis’ actually works.

What really surprised me is the fact that we actually did some great talking about Agile Software Development, although this is in the next session I will give in April…

Most Software Development Project start with the same thing: somewhere in an organization, someone gets an idea. And there’s where our challenge starts…

All ideas tend to have the same properties: there not specific, unmeasurable, it’s not clear if there achievable, there non-relevant and specifically: there not time-bound. In other words: there not SMART. And no: I’m not saying there, in essence, not Smart (a completely different thing, if you ask me).

This is, in my humble opinion, the sheer beauty of it all; it’s all measured in perception, emotion and (personal) opinion. But we’re in software: so that’s an exact science isn’t it? (Of course it isn’t) At least, we need to make something, create that idea. But how do we make it SMART? Or don’t we need to do that?

In most project you see the first, we put lots and lots of effort in making ideas SMART. This means that, before we even start thinking about writing some actual code, we have spend lots of our precious resources in capturing something thats basically an emotion into specific and measurable elements. Weird, isn’t it? (Sounds pretty masculine too.)

Why shouldn’t we try to keep the idea into the ‘emotional’? And simply try to proof the hopes that lye beneath that idea? Any Idea, at least in our line of business, contains something we actually need to capture: the problem. Focus on that, and then we can finally find out where the value is to be found. Even within an Idea.

Assumptions are Lethal. This is a thing we probably can be sure of. Maybe lethal is an overstatement, but you guys probably know what I’m talking about. Actors in our projects that don’t seem to listen, because they already ‘know’ how the solution must look like and how the functionality works.

Creating an extensive Functional Design even doesn’t really makes sure this is avoided, because people still need to read it in order to understand what the functionality we need in our system. After implementation we can still hear those scary words: ‘Oh, I thought that…’

Thoughts are not what counts in Software Development, value is. Therefore design and analysis are useless, when you don’t properly share with your peers. Spend most of your time talking, explaining or simply measuring. We simply cannot rely on the Divine to explain the functionality to the actors in our project.

Therefor we need to make sure the functionality is understood. One of the easiest ways is to create a situation where actors get involved in designing and deploying functionality, in any kind of project. If you ever hear the words ‘I know how it works’ again, be extremely aware and drag this person into your project to make sure he (or she) really knows how.

For this simple assumption I leave you with only one tip: Analysis and Design isn’t a one man show, it’s a group process…

Right now, I’m creating a presentation for a session I will give on wednesday at the Fontys college about Analysis and Design. Even on the first slide, I created a deadlock for myself. I state, the only real value is to be found in a working product.

So, I would like to state the obvious, analysis and design are there to determine where we can find the value for the customer, or end user. But don’t we need to make it more measurable? Without making it an extensive and, therefor, expensive process.

Analysis and Design in an Agile Software Development project is an ongoing process. We need it to set the boundaries in which we can develop. Analysis is used to create a common goal within our project, Design to create a vision for our project. We need both to make sure we create real value on time, within the budget we determine.

Where the value is to be found, and what this value is, is determined and facilitated by analysis and design. Therefor we need this phase in our projects. It doesn’t mean we need to document extensively. Documentation in this phase of the project only is needed if it creates value.

There we go, analysis and design actually do create value within our project, because it shows us where to find the value for the end user, or customer, and how to implement it. Just do it without the right approach and with a ‘lean’ mind.

This morning, after I woke up, I read an email from the Oracle ACE program. And read it again. I couldn’t completely grasp what was going on. Now, a few hours later, it looks as if I just got one of the largest compliments anyone in my (our?) line of business can receive: I am an Oracle ACE.

I really feel honoured, this is a great feeling and it shows me that I do the right things for the Oracle community. Louis-Guillaume Carrier-Bédard nominated me for the Oracle ACE award. (Thanks for this Louis-Guillaume!) He is one of the great people who sacrificed their spare time to review my book on Oracle Forms conversion to APEX.

The Oracle ACE Award is issued by the Oracle Corporation and the choice is made on ‘People who have made a significant contribution and activity in the Oracle technical community’.

Thanks! I’m honoured.