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.
