Architecting your IT projects. Problems and solutions

Architecting your IT projects. Problems and solutions

In this video, I will show you how easy it is for the bad software architecture to kill your IT project and what difference a good architecture can make.

When you start any new IT project, you start with an idea.

There is no documentation yet.

In many cases, management knows everything about what needs to be done, but does not know anything about programming.

You hire developers and they spend their time in meetings trying to understand what needs to be done.

They talk a bit then hack something…

Talk some more, go hack something else.

There is no central point of knowledge, so your developers bug you for more info every day annoying the heck out of you

Your project tends to be very expensive and takes a lot of time, because your programmers code everything from scratch without looking for any alternatives.

The more code you hack together more complex your project will be.

Without any documentation things that look simple – become large projects since everybody is busy hacking even though it is very possible that these components can be found readily available on the Internet ready and tested by somebody else.

Speaking of testing, just imagine how complex testing this whole thing is.

It’s a complete nightmare…

The more code you write, the more possibilities for problems you create, and it’s especially true if your whole architecture is built in such a way that every module you write is dependent on every other module.

This means you cannot test anything separately and you have to wait to the end to test one huge piece of code that literally falls apart in your hands from the smallest touch.

And of course with this process, your final integration is a LONG and nerve wracking process. You just throw raw pieces together. None of them have been tested and you run between every piece of code not knowing where to throw yourself next, because NOTHING works.

And even when you somehow get over this and release “something” into production and people start using it, it doesn’t mean that it’s ready.

It just means it was “reported” as ready, but it crashes every 5 minutes when people start using it under real conditions. So you just switch from integration mode into maintenance mode which is 10 times harder, because now you have to react even faster since people are stuck and keep calling you every 5 minutes.

At this stage you usually find out that there are a few things that you misunderstood in the requirements and you need to change it or even add new features, because people cannot use your software without these additions, so not only do you have to fix existing problems, but you have to add more problems by introducing fresh, untested code into more untested code.

But what’s even more alarming is there is no documentation whatsoever – everything you know about this project is in the heads of a few programmers.

God forbid some of them decide to leave at this stage, which happens often. The project is “done” and they move on to some new and interesting stuff to destroy…

So now the blaming game starts and bugs are really hard to fix since everybody blames the guy that left and nothing gets done.

And besides, if all the information about the project is in your head it’s pretty useless, but at least it’s not dangerous.

If it’s in your programmers’ heads, you just made yourself a hostage.

They can demand anything they want from you because…

Nobody knows what goes on inside the code besides them.

No documentation exists.

The project is over and your budget is spent.

It’s also pretty hard to hire new people, because it will take you 5-6 month to get them up to speed on everything AND you have to take time away from your other programmers and they are not really cooperative, they see it as a threat to their job security.

Does this sound like a lot of stress?

Let me tell you, if you have never been in this situation, you don’t know the half of it.

I have seen it go to the point where the owner ran out of money and stopped paying salary to his employees.

That’s what not having good software architecture can do for your project, but fortunately it’s not all that bad, because there is a simple and elegant solution.

There is a good reason why this whole game is called R&D. RESEARCH and development. Notice how research comes first?

So before you even hire your first programmer, you need to do your homework and think of what needs to be done and how.

Let’s see what you need…

Before anything, you need to answer two very pressing questions.

First, how much money is your project going to bring you? Really!

Of course it’s not exact, just a rough idea of what to expect is enough.

In some cases you don’t have to do anything further, because the market you selected is just not big enough for your company.

But if the number you get is good and you decide you should continue – you must answer the second major question…

How long it will take you and how much it will cost you and at this point you MUST have a good architecture, because your schedule and your price will depend on how good it is.

And of course, when you know THAT, you can calculate your ROI.

Let me tell you, this is REALLY important…

According to statistical research, over 80% of all IT projects return less money than they cost.

What is more important, after you go through this, you will have a very detailed written requirements and a solid architecture you can use in your project.

You will also have a very detailed schedule with optimal number of employees and their roles for each task.

And yes… you will change parts of it and yes… it will be adjusted a bit in the process because it’s not written in stone, but in my experience from 100% of the projects that have this documentation, even though it’s not exact, 100% of them are successful.

Right architecture usually cuts your development time quite a lot.

For example if you want to build a web site and connect it to your inventory… hacking approach would start writing everything from scratch and this project could take a year and cost you 2-3 hundred thousand dollars to build easily.

On the other hand I would just take a pre-existing content management system and write a plug-in to integrate your pre-existing inventory system into it.

This would take my programmers a week to do and will cost you a 1000 dollars.

This is by the way, a real life example from my experience and it happens all the time.

So, here is the algorithm I use to do a good architecture.

First you must understand the requirements fully and write everything down. It should be as detailed as possible. If you have any user interface, mock it up so that you will have the look and feel done. You also need detailed understanding of how everything connects together and what number and type of clients do you have on the system to calculate the load.

Now check to see if there is a solution on the market that does all or most of what you want to do. Chances are you can either get it free or buy it which will save you a lot of time and money.

If it’s not possible, you will work on splitting your solution into logical pieces that can be completed separately.

For each requirement you ask a question: “Can this be done in a separate module?” For example, a database module, reporting module, web site module and perhaps some mobile module to let your remote sales people connect to your system.

Now you distill the requirements for each piece into HOW to do it.

For each module, check if it can be done by software that you can get free or buy.

There will also be some integration paths between different modules. You strive to make your database the central integration point as much as possible, so for each piece you also check if it’s easy to integrate and if it’s possible to test this specific piece separately.

If you MUST write some code, see if this module can be done simpler until you find the simplest possible approach that will allow you to do everything you want in a minimal amount of code.

Decide what programming language and what architecture best suits your application. For example if you are doing off the shelf product you may want it to be platform independent so it will drive your programming language.

As you can see with this architectural approach, problems I mentioned before do not even come up.

After you hire your developers, none of them need to discuss the solution. They can immediately start writing code from day 1.

Your project is a LOT cheaper.

Your development time is very short since it is mainly an integration project.

It’s very simple and transparent, everybody knows what needs to be done and there is detailed documentation for every step of the process.

Testing is also a no brainer. Most of the code you use is done by a large respectable firm and has been tested by thousands of users before you.

Those small pieces that you code for integration require minimal testing and they are also designed in such a way, that you can start testing them separately without waiting for the whole project to finish, so when it comes to integration, every separate piece is already tested to some degree, so you do not end up with a big mess like before.

Yes, you find some bugs, but it will be nowhere near the mess you would have before.

Your release path is cut out for you, since most it is just installing third party components on a single server. This can be done in the beginning, so at this stage, only some small integration pieces are installed and started.

Additional benefit is since each piece of your programmers’ code is designed and tested separately, it can even be put into release separately AS YOU GO.

This allows your users to see how everything will look like BEFORE you actually release.

They can make some changes to individual modules if they see something they forgot and because modules are designed independently, these changes are quick to accommodate and most importantly…

They do NOT break any other module.

But even these changes do not happen often, because you took some time for research and made very detailed requirement documentation.

You have no dependency on your programmers and they can come and go. All you need is a programmer with the knowledge of generic components like specific database you use or your specific reporting solution AND all your integration pieces are well documented, so it takes no time at all for them to get up to speed.

I know it sounds like heaven for anyone involved in an IT project and reality is obviously not that rosy.

But it’s really close. Of course any IT project is going to have a few bumps, but it will not be anywhere near the amount and complexity you would have with the “classic” approach.

After doing quite a few projects this way myself, I can tell you this approach will eat any “classic” approach for breakfast and will leave it in the dust.

I use it with all my clients and with my own software and it’s a guaranteed winner.

If you like me to do the same for you or you have any other questions regarding this approach, you can visit my web site at the link below and give me a call now.