Developing a software product is akin to building a house. You have a plan when you start building the house. With computer models, you can pretty much visualise the entire house, space, things that will be there like sofas or ward robes or others and get a feel for the entire house before you construct.
Why is it not the same with software? We still have this practice of drafting requirements in English which the author himself would find it hard to read after it is written.
There are models based on UML as well which may be better than text. There are user interface mock ups which give an idea of the front end. But still the programmers who are essentially the masons and carpenters and plumbers of the code that builds the product has no way to visualise the entire house the way the plan shows.
You may say that the masons of a real building may not know the entire thing and it is the civil engineer or the architect who has this mental model of the entire building. Agreed. But this is where a big hole is left open in software. Building a wall which forms part of a bigger plan is known up front when a building is constructed. However, in software this is not really true. The reason being the requirements themselves are vague many a time on a document. Further, the design based on UML or other diagrams are not frozen before coding begins. Though the waterfall models strictly mandate this, there is always a overlap of phases and with agile models and go-to-market strategies things have gotten really worsened to the point that you often end up scrapping the whole effort done earlier to begin a brand new build out. And we come out unscathed giving justifications for such acts eventually growing the mistrust on the programmers guild.
The biggest difference I see is, the requirements for a building are easily visualisable. And hence a wall that is done somewhere in one corner of a building is easily visualisable as well. If we ask why requirements for a building are easily visualisable, it is primarily due to the fact that you see houses all around you all the time. People right from when they are kids have a sense of buildings around. They play with building sets, they build castles on the beach sand and we live in them. So the sense of buildings are easily ingrained in us. It is not something like an effort has to be made to bring it into a visual form. Of course, complicated structures, aesthetics and so on may require hard thinking. But a engineer or an architect can do this in his head and bring it in a virtual reality model using a tool that can be seen and visualised easily by others. So it is easy to freeze the needs between the consumer and the producer.
If you take the case of software, the consumer varies in degrees in terms of the knowledge of the domain and may not know what software can or cannot do. Same is the case with the software guy who does not understand the business side to be able to speak that lingo with the consumer. There are nuances in every domain which only the experts in that domain understand. It is mostly a case of people, processes and the way businesses have been going on which is what the software tries to replace in parts or whole. How do you model this like the way you visualise a house?
If we take the different components of a software, each of them may expose interfaces for a consumer. Say, we are designing a software that brings together people in healthcare like patients, doctors, hospitals, diagnostics labs and so on into a platform where they exchange things. Now to solve this, if a graph database was chosen, which exposes APIs that allow the user to add, link , traverse and so on. All of this makes sense for the software guy. But how about the healthcare folks?
If there is a visual representation of the 'business data' of the health care domain shown to enter a box representing this graph database and the data coming out of it or the ability to see the connected graph of the business information for one or more use cases that is produced as a result of interaction with that box which is the graph db, then everyone involved including the person constructing it will not miss the point. However, this can still be missed by the domain people who do not get what a graph db is or how it helps their case. How do we bring these two people together?
This is where I feel we can use the analogy of a building itself which is familiar to both the parties and which in parts can be likened to software construction.
What I say here is a sort of convergence of the business domain and the software architecture / design. The software architecture is not done by having components and connections and interactions and flow diagrams independent of the domain experts. The business domain experts can make sense of the flow of the information into the 'user interface' which is the most visible part and be able to see changes in the user interface.
The underlying parts which result in the computation are all now shown as a person walking in a house from one room to another, from one floor to another and coming out. It is sort of a model of a house with floors and rooms where the data payload is a person who starts somewhere say ground floor in a room which is akin to the component that exposes a REST API and starts going into the different parts of that room say cubicles that does some transformations to the payload which is the person himself. The person's look and feel changes as he walks through cubicles and rooms and floors which are the different layers of the software. The person may grow in size that is akin to the payload growing while traversing a room of a certain layer for example. The person may come out of a cubicle or a floor or a room based on O(n) computations that happen within them. If he takes more time, we know there is a large amount of computation necessary or unnecessary as a next step.
This kind of visual models like a house, building and people where we are more comfortable to associate with than the flat diagrams with its own notations can often give a quick sense of what is going on for every one right from the business folks to the coder responsible for a module. I some how feel that this can be done with Lego bricks. The only difficult part is the morphing of the person walking along as he visits a room or leaves a floor with the computations or impacts created in that place. Even if there is a 3D model of this in software it looks like a interesting and highly potential software tool that can pretty help to accelerate the way we architect software in the future.
If there is a visual representation of the 'business data' of the health care domain shown to enter a box representing this graph database and the data coming out of it or the ability to see the connected graph of the business information for one or more use cases that is produced as a result of interaction with that box which is the graph db, then everyone involved including the person constructing it will not miss the point. However, this can still be missed by the domain people who do not get what a graph db is or how it helps their case. How do we bring these two people together?
This is where I feel we can use the analogy of a building itself which is familiar to both the parties and which in parts can be likened to software construction.
What I say here is a sort of convergence of the business domain and the software architecture / design. The software architecture is not done by having components and connections and interactions and flow diagrams independent of the domain experts. The business domain experts can make sense of the flow of the information into the 'user interface' which is the most visible part and be able to see changes in the user interface.
The underlying parts which result in the computation are all now shown as a person walking in a house from one room to another, from one floor to another and coming out. It is sort of a model of a house with floors and rooms where the data payload is a person who starts somewhere say ground floor in a room which is akin to the component that exposes a REST API and starts going into the different parts of that room say cubicles that does some transformations to the payload which is the person himself. The person's look and feel changes as he walks through cubicles and rooms and floors which are the different layers of the software. The person may grow in size that is akin to the payload growing while traversing a room of a certain layer for example. The person may come out of a cubicle or a floor or a room based on O(n) computations that happen within them. If he takes more time, we know there is a large amount of computation necessary or unnecessary as a next step.
This kind of visual models like a house, building and people where we are more comfortable to associate with than the flat diagrams with its own notations can often give a quick sense of what is going on for every one right from the business folks to the coder responsible for a module. I some how feel that this can be done with Lego bricks. The only difficult part is the morphing of the person walking along as he visits a room or leaves a floor with the computations or impacts created in that place. Even if there is a 3D model of this in software it looks like a interesting and highly potential software tool that can pretty help to accelerate the way we architect software in the future.
No comments:
Post a Comment