Application architecture concerns

Sponsors interests

Know who the sponsors are. What their motivations are in bringing a software product. Is it a brave new thinking and disruption in terms of a idea that they want to realise or is it something that they want to bring in as a refinement over a legacy product that lacked architectural thinking. 

Will architecture change because of the above?  Architecture for a new idea or concept is not a real need in my opinion. A brand new product which is yet to see its customer base has other challenges like bringing a early version to the market as a Beta even to understand and refine the thought. Architecture for this would come in the way of realising this early versions. Short cuts even if they mean rapid prototyping with minimal design thoughts are good enough. When there is a demand for the product and it is steadily growing, then things like scalability, performance, availability all comes to the fore. What this means is architecture comes at a much later stage in this case.

The second category is a total product rewrite to replace a legacy product. This comes with a clear idea of existing customers and potential new customer base. This definitely require a clean architectural thinking right from the beginning. Architecture helps to avoid making mistakes of the legacy product that would have made it a burden to maintain, evolve or penetrate new markets. That normally would be the reason why sponsors would want to bring a architecture base. 

Bringing in a architecture early on structures the thinking around all the issues that floats on the surface of the legacy product over time. Also, a new architecture helps to get a leap to a different level taking advantage of the technical, technology evolutions since the legacy product. 

A third category is about re-factoring an existing product. This also require architectural thinking. But this most often may not be easy to have a cleaner structural arrangement as a total product rewrite. Re-factoring is mostly the case with legacy products as against a complete rewrite due to the cost, time pressures to bring out a better version to the customers. Often if the original product was shoddily designed, customers would bring in the pressure to have a better version as they would be bearing the brunt in terms of frequent patch upgrades. This triggers a re-factoring rather than a rewrite to allow for a quicker and better release. 

A re-factoring is always tricky than a rewrite because of the fact that it is always difficult to make sense of some one else's code. It is always rare to see a design or architecture document that is up-to-date reflecting the code which makes it even more difficult to achieve a clean partitioning. Thus re-factoring majorly is always a dream unless the original design team is remaining intact in full or part.

Application architecture concerns

Continuing the key concerns on the application architecture,


Cost of product development plays a big role

If the proposed architecture results in a lot of labour it is usually shot down no matter how good it is. This can also happen due to lack of skill thereby requiring more time to realize the architecture by the team. Budget is always constrained in organizations, especially for new ventures. Architecture will be even more constrained when developers decide to code something quick and be able to handle the short term need. If the product becomes a hit, demand picks up and all the issues come to the fore.

If it is a web application, this model works perfectly fine as the initial budget is invariably small and nothing in the sense of a scalable, reliable architecture can be done. The broad outlines can be specified in terms of the components, interfaces, functions and then the plane takes off. If the product is a hit, more funds are available and scaling can be addressed at that time. Most of the time the users are also individuals and the fee collected per them is not significant to be precise in terms of delivering a fool-proof architectural answer.

However, if it is a enterprise application paid in millions by the customer and used by millions of people of the customer such as a telco application, then short-term solutions turn into nightmares later driving the project into a death spiral and ending up having a irated customer. Architecture in such a case should be given a serious thought. In this case, the cost of having a architectural underpinning is usually insignificant compared to the size of development. Or in other words the cost of architecture should not exceed 10% of the product development cost to give a rough idea. This I believe if executed correctly should give the benefit of reduced labour resulting in lesser cost of incremental development of the product and a quicker turnaround time in releasing new features.

 It would be suicidal to go with a non-architecture approach for a large enterprise application. As the number of users increase, the size of data goes up, the rate of failures due to bugs, the predictability of performance and scaling comes to the fore without a sound architecture. Bad architecture always comes to haunt a product team at a later stage when the number of users increase. Citing cost or schedule pressures in avoiding architecture is not a sensible thing in this scenario as cost due to adhering to a architecture is always lesser when compared to the cost of an adhoc development and resulting rework.
 
A well thought out architecture results in the simplest and best way to address a problem. However, this means the problem should be correctly stated as much as possible. If this involves a cost, it is  money well spent. The hassles of spending money on a imaginary problem is far worse. Often cost overruns happen due to incorrect perception of the problem and a improper answer. For example, a requirement that says the requests will hit the application at 10 TPS (transactions per second) if in reality is at 100 TPS,  not having a Cache or a light weight framework in the architecture may cost the day for you.

There is no idealistic architecture. It evolves over time. Thus, it is important to spend money to refine the architectural thinking with prototyping. If multiple options can be tried quickly and the best technology or approach is identified, then it saves a lot of money.

Application Architecture concerns

Not all the applications need a architectural thinking. If you are building a product that has to stand the test of time or go for a long innings then you better get an architectural underpinning for that. If it means a large number of end users or it is going to run on the cloud, then it is a must to have this aspect nailed down. Most of the web scale products we see like Google or Amazon platform would not have been developed with a scalable architecture on day one.

But what I have seen is, even if you want an architecture underlying your software, and even if some one is deputed on that task from day one, the final architecture is proven only when it meets the desired scale, performance, flexibility over time. This will not happen in the initial days or months.

Architecture cannot be fixed in the initial weeks or months of a product and then onwards we can see the product following the same. It is absolutely not possible. Of course, the initial structure of the product can be laid out based on the requirements available at that time. However, as we have seen, requirements are not cast in stone. It is almost close to making the writing on water. It changes over time so drastically. There is nothing wrong about it if you leave out the 'get me this out by Monday' type of pronouncements. That's the way things are. In a way the 'agile' methods make more sense to the sponsors due to this. They do not need to wait infinitely to see the product in its full glory. Because requirements can change, architecture, design changes, implementation changes, if some one decide to wait for the first perfect release it becomes a mythical thing. So, give me value for the money I put in. Show me something that is in tune with the current stated requirement. That seem to be the mantra. In a way, the architecture also has to be moving in this path. It is true that architecture cannot be so damn fluctuating as a product evolves. The basic structure should be in place to address the key concerns. Then it is a matter of how course corrections are done to accomodate the NFRs like performance, scalability etc. That does not mean the initial architecture focuses on functionality only. Functionality should be obviously addressed. But care should be taken to ensure non-functional aspects like performance is also discussed even in initial stages.

So it becomes important to focus on the key concerns and what could they be?

Before even looking at technical or technological considerations, some of the key aspects that has to be understood as a architect is

- What kind of audience will be using this product?

In most cases, applications are used by people who may be well versed in the business domain. For example, if it is a application that automates the processes in a automobile manufacturing industry the product should be talking about their final product which are the cars and how things move around to get the processes involved in getting a car ready. The domain people who are well versed in a manual setting in manufacturing a car are the audience, apart from administrators who are a little bit more tech savvy and who may define workflows or rules or the CEO who is more interested in a summary outcome. Thus it is important to understand these people who will expect different things from the product you give out. The product should be able to meet all of these diverse view points and their skill or capability to comprehend out of the product and map it to their own needs. You cannot ask a supervisor of the plant to define rules. This has to be done by some one who is computer savvy, trained to handle the rules and processes. The CEO cannot be asked to define rules as well :-)

These are very finer details not touching any of the details of the product you make but more from the view points of its users.


- The ecosystem where the product will be deployed

Normally with tiered architectures, the deployment is going to be clients and server side. However, there could be people on the move such as salesmen or people who need to monitor things around the manufacturing facility. This may require mobility involving smart phones or tablets and others. This will impact the amount of data you can push around or other latency considerations. The product may have to be running on multiple sites across a country with local caching and ability to handle synchronize it with a centralized DB. The product may be a carrier grade one requiring geographical redundancy requiring the architecture to bring in questions early on during architecture definition such as the choice of cache or messaging technologies.

Will discuss more in the next blog..