Conceptual architecture or technology stacks?

A lot many times I end up seeing designers / architects drawing technology stacks when showing the architecture.

Architecture to me is always independent of technologies. Architecture is a sort of blue print addressing the concerns. It has many views and a technology stack that fits the blue print is one of the views.

Mainly the blue print should be able to have blocks which addresses the different functional requirements - sort of a broad sweep. For example, if the functional need is "Integration with one or more southbound systems" then a block which maps to it having inner blocks representing "Adapters, Transforms, Endpoints, Routes" as some of the labels of it would give an idea that the southbound integration is addressed by this block.

Now there can be many blocks representing different functional needs. It is important to be able to specify the interconnections between these blocks and specify the type of protocol.

The entire system comprising of the different functional blocks should be given a view in terms of the ecosystem where it resides. The systems and applications that connect to this system whose architecture is being defined. The ingress, egress points have to be specified along with the protocol.

As another view, the physical view or deployment view can show these blocks as processes, libraries, clusters, physical interconnect etc. This gives an idea of how the above functional blocks are realized and represented in the real world. The deployment view can also label the exact technologies like Hibernate or Drools or J2EE or others to give a better idea of the physical view. The physical view typically shows the single node and cluster deployments.

As another view, the most significant call flows through the architecture can be highlighted by way of a sequence diagram across the architectural blocks.

Essentially what we are showing is the way the overall system under question is viewed from different angles like the way a house is seen from the front or top or dissected to see the internal arrangement of the rooms or the passages connecting them and a even high altitude view to see how the other houses and street are where the house under question is situated. It is quite similar.

This way of representing in different views or dimensions help answer different aspects of the architecture early on allowing others to comment and refine the picture. It gives the broad guideline for design and shows the way all through implementation. If the original blocks have not been violated over course of time in spite of the varying requirements through a project, its a sign of good abstraction of the problem in hand.

The key here is the blocks should not be overtly high level and general that it is useless to relate the problem to it. It should have sufficient detail to give a clear understanding of how the underlying design will work at a high level. At the same time, it should stay away from too many details which if you think will be better served to be handled during the elaboration of a block during design.

Architecture should not be seen as mere pictures. They are the outcome of a experienced person solving the entire complex problem with its multitude of requirements in one go at a broad level. It should address all the key requirements and should not leave anything. It is one broad stroke with a paint brush covering the final outcome. Details are missing but can be filled in during the course of design.

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

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..