Enterprise Architecting the right way: A money saver

I was having this discussion about Enterprise Architecting with a colleague the other day. After being elevated to the position of a Technical Lead/Product Architect, you never really get to do much but discuss (about how to get it done, among other things ;) ). We never knew when the discussion changed from a harmless talk to a heated argument. But at the end of it we agreed on two points. The first and the primary rule about Enterprise Frameworks and Applications is: don't do it. The second rule is, if you must, keep it simple. Think about these advises and I assure you, as a software company, you will save a lot of revenue. I have justified my opinion in the following simple 'to-remember' points.

1. DON'T GET ME WRONG

You might wonder what kind of an advice that would be. Don't do it. Of course, we want to do it. We want to build a product or a service.

Don't get me wrong. I am not advising against creating a product or service architecture for client companies. The advise states that, do not complicate the matters trying to come up with a very complex structure for the implementation. And in most of the cases, it turns out to be the other way round. People tend to make it complex to make it look nice to the client. Actually. And the clients seem to like it.

I am not implying that complex is bad. But in my years of experience, I have seen unduly complex architecture tending to be useless beyond the first time. Such architectures are rigidly built. Hence they are not that flexible to accommodate much customizations.

The problem, here, is that with more and more client implementations, the software company becomes loaded with more and more complex and huge architectures per implementation with probably a lot in common. This leads to recruiting more developers and keeping them on board simply because, we need to sustain the implementation of these architectures. Why? Because a client somewhere might be using it. An enhancement/bug, and the there must be someone to address it.

Simply put or deduced, the cost incurred by the software company rises exponentially.

I have enlisted some of the specific cases at the end, if you are interested, where some of the companies(no names of course :) ) I know, have made some serious mistakes. The intention of this blog is not to bash companies up. It is to point out where you can avoid making such mistakes. I will keep updating the list.

2. KEEP IT SIMPLE

As a software company, you should be more worried about making and using a reusable set of components as a part of the architecture. Break the structure of your product/service down to such a level that developing it in a modular fashion would be a cinch. The design phase of a project (product/service) is meant to identify exactly this. And we end up missing ONLY this.

Don't worry people. It is not rocket science. It is very simple. BREAK IT DOWN and PLUG IT TOGETHER. Believe me, down the line, most of the components will get reused. And you need a smaller set of workforce to tackle issues/enhancements with these components. This way it is not only efficient, you save money with lesser workforce and also plan for the future.

3. BREAK IT DOWN and PLUG IT TOGETHER

In the design phase, if you observe, a company is ready to invest a lot of time and hence money in tackling the specific issue. Nobody (sorry for the irresponsible allegation, but there are times when the truth must be told) invests even a little amount of time/money to go one step beyond and see if anything can be made reusable for the future. Or even reuse something from the past projects. (Believe me, I have heard from a project manager saying,

"Ok, I think we need to redo this module for this current project. Using something from that past project will require some customizations. No point in using that".

Or something like

"Umm .. thats not the problem we are trying to solve Jay. I need you to focus on coming up with a specific solution to this problem. We will worry about it if ever the need arises."

to suggestions of making something generic or reusable that seems like it can be.)

I am sorry if it seems like that post where a frustrated employee takes on a manager for something he might have done. This isn't the case. But these are the cases where you have to get it right.

4. HOW DO I DO IT?

The correct approach, according to me, is have a split design phase. One part of the design phase focuses on the project deliverables and then detailing at the technical level. Once this has been established, the other part of the phase is to identify the reusable components from the past projects and those which can be made reusable now. To start off, this phase induction is good enough to get us started on the re-usability.

Otherwise, think if all the hardware of the world or all the cars in the world were to come as one solid single piece, what good would it be?

I will cite the instances as soon as I compile the list.

Solution Consultants : A Philosopher's Stone

Congratulations !!! If you are reading this blog, it means, you have already taken the decision to use software to solve your list of business issues. Most probably, by now, you must be inviting proposals or receiving them from prospective vendors for the same. If you are at this step or just before it, take a minute to read this blog. I assure you that you will start thinking more clearly after this. Or atleast, this blog will give you an argument to consider.

Some simple observations.

1. WHAT DRIVES THE DECISION

How does a business decide when to implement a software solution for its needs? 9 out of 10 times, it is the business users or the customers of a product/organization that drive it to take the decision to implement the software. This is, then, taken up with the CTO who drives the implementation. Sometimes the CTO becomes emphatic to the fact that the organization is doing too much of its work in the most favorite spreadsheet solution. The need for the software is born.

2. PROPOSALS FROM VENDORS

The CTOs, then, spread a word amongst their circle trying to look for vendors. They also contact re-engineering consultants who look for vendors in their circle. These vendors forward their proposals after understanding the detailed requirements and, if possible, arrange for a demo of the capabilities of their software tuned to the CTO's requirements. The word spreads around and more proposals start flowing in.

This is a traditional approach of getting software implemented. Pictorially, it can be depicted as below:

3. ISSUES AND INVOLVEMENT

The problem with this approach is that, the CTO and his team ends up spending a lot of time in this process. The pain doesn't end after finalizing the vendor. Once a vendor is selected, the CTO will now need a team on his end to follow up with the vendor from the requirement phase to the implementation and then onto support. You can see the involvement of the CTO's team's involvement from the picture shown below.

Enumerated, it will appear as:

1. Arrange and participate in the discussions to explain the requirements to the vendor (MOST IMPORTANT).
2. Initiate the development cycle and track the progress of the development (all the phases in the software development) eg. the Go-Design, Go-Develop, Go-Test, Go-UAT, etc.
3. Follow up with the vendor in case of any changes.
4. Raise software change requests, approve invoices, finalize effort estimates for changes and development, etc.
5. Create detailed test cases for the phase.
6. Test the software.
7. Post the software for the business users to test (UAT).
8. Production deployment.
9. Arrange for support vendor/team to manage support once the software goes live.

etc.

4. PHEW

Guys! The CTO does really work hard.

5. SOLUTION CONSULTANT

Here is where the Solution Consultant come in the picture. They are the people who do the chunk of the work for you. Think of them as the people who will do it for you or find someone who does it for you and then get it done. A CTO's true friend.

A solution consultant is the entity that gets hired the moment a CTO starts thinking of software implementation. The CTO is now, least bothered about who, how or what.

1. All that he/she knows is that a vendor has been finalized (of course, based on careful introspection only). The difference is that, now the CTO has access to a wider range of solution providers. Doing the market research and finding the best vendor is the job of the solution consultant. The CTO will now know that a vendor has been finalized and the grounds on which it was.
2. The solution consultant will then track the software development life cycle phases with the vendor. The responsibilities to finalizing the time estimates, approve the cost, technology decisions, etc. still lies with the CTO. But now the CTO doesn't have to sit and figure it out. The architect does that for him/her.
3. The change requests, bugs and their fixes, software licenses and agreements, etc. are kept track of, in detail.
4. The solution consultant worries about the implementation of the new software and its integration in the existing architecture after the implementation.
5. While the system is being deployed on the UAT, the solution consultant arranges for the test cases. The business users perform the UAT based on these test cases.
6. And much more...

6. WHO ARE THEY? WHERE DO I FIND THEM?

They can be absolutely anyone; either an organization that specializes in offering these services or individuals who do the same.

7. WHAT IS THE POINT, I AM TRYING TO MAKE?

All the CTOs out there, before you decide to implement a software solution yourself, explore this option. Whats the harm? What do you have to lose? You were going to work hard anyways ;). Get it done from someone else for a change.

[All the above view points are my perceptions based on a very fruitful career in software industry. I have seen Sales Directors, CTOs, CEOs, etc. actually throw money (not just out of choice but more out of compulsion as well) at anything that resembles what they need as a software implementation and the software companies actually milk them dry for this.

More often than not, the customer needs 'x' set of requirements. But in their search, the customer ends up with a vendor that has a product with 'x-y' set of features. The rest of the features are charged heavily as a customization

I, hence, decided to educate/warn the concerned about the ill effects of such an approach. This is my first (very first) blog on giving something back to the community. You can expect more.

Kindly provide me with your feedbacks.]