Logic VS Art in writting errors

As I sleep in my cosy blanket on a beautiful winter morning, I get a call from my onshore teammate (who is in a timezone where it's still morning). My teammate is panic-stricken and screams, there is something wrong with the production site, and we can't fix it!

Still, in my bed, I asked: "what is the error?". I get a feeble response - "It simply says - Something went wrong. Please contact the site administrator!" 

And then the journey of debugging begins. It is like shooting in the dark and hoping (and eventually praying) that arrow hits the bull's eye. 

Hours of frustration and effort, one discovers the bug. The issue was, someone had removed the rights from the folder to make the file write. 

Though simple, many a times, we end up spending hours in finding the issue or bug. And this not only causes frustration, sleepless nights but also makes one lose face to customer and customer lose their image to their users. 

So, how to handle such situations! 

Best answer could be, write systems such that they never have an error/bug. OR Test the system for all possible scenarios and fix any potential error.  But that is like living in an idealist world where alians and humans are friends and meet daily to have breakfast together.

Given that we don't live in such an idealist world, what do we do?  

IMO, we have the exception messaging system. Any exception, the message logged or displayed should be clear enough such that it directs the engineer in the right direction and fast. 

Let us break this discussion into two parts. 

Part One - What, where and when to capture errors. 
Part Two - How to display the error messages (after we capture them).

Part one is relatively simple. We put exception blocks at all possible places where the given logic can go wrong. And one should collect all exceptions in a central location. Use following principle to address the approach:

  • Centralised exception logging
  • View and search all exceptions across all servers and applications
  • Uniquely identify exceptions
  • Receive email alerts on new exceptions or high error rates

I am not going to spend a lot of time of part one because it requires more logic than art. 

Part two of this discussion is where we have to worry about "how" to capture or write or display the error/exception. 

Before we get into the "how" part, let us figure "where" all we capture/display the error. We catch/display the error in/at:

  • Logs & Audit trails
  • User interfaces (screens)
  • Email
  • SMS

And we can't apply the same rule of showing/capturing the identical massage everywhere. 

Depending on the medium, we have to change the text and decide on to what extent it has to be verbose. 

Hence, we can:

  • Know the audience (an engineer vs user)
  • Capture about the what and why it (error) happened
  • Suggest next step 
  • Show the exception 
  • Automatically inform the right stakeholders. 

From the above steps, all are logical. What requires more than logic and instead an artistic touch is where we are to display the message. 

We can, however, keep in mind the following guidelines: 

  • Let the message be not too technical:
    • e.g. "Due to unhandled memory (0x001100) allocation, the bootstrapping is failing" 
  • Let the message be not too simple:
    • e.g. "Something went wrong"
  • Let the message be not too kiddish:
    • e.g. "Opps! Sorry mate, something ain't right. TTYL"
  • Let the message be not too informative (sensitive)
    • e.g. "The access to folder ..\system\files\ is prohibited." - Displaying the server path is not a good idea. 
  • Let the message be not too stupid: 
    • e.g. "The password you have entered is same as that of user 486360. Please use a different password to create your account."

Hence, while writing/capturing messages, try to empathise with the developer who is going to debug it and also with the user who is going to read it. 

Errors give rise to stressful and serious condition, and a silly tone would be inappropriate. So, keep calm and provide that non-scientific touch while writing error messages. 


Call any architect and get it fixed. - Understanding different types of architects.

There comes a time in the project when the IT project manager or the delivery manager will scream and exclaim "I need an architect!". The manager is facing acute performance or security or practical issue that he feels only a technical expert can fix. And that expert has to be an architect! 

Within a week, preceded by many escalations, the team finds an "architect". The architect comes and understands the problem. And the solution to the problem lies in the design. The design is not scalable and needs to be re-engineered, informs the architect. 

Fine, says the delivery manager. Fix it is the expectation. But the architect says - "I am not hands-on with programming since some time but can guide a tech lead!"

Disappointed and agitated delivery manager is not happy with the architect's "attitude" to solve the problem, but he feels that the architect is trying to deflect responsibility. However, the architect stands his ground suggesting that he is a solution architect and cannot fix the issue by revamping the code.

A myth associated with the software architect is "he/she could & should any technical issue that the project team is facing". 

This article tries to explore the myth or wrong expectation from software architects. Specialisation is paramount when the amount of knowledge in the given field exceeds a limit. And since the software architecture is a vast amount of experience, it is essential to reduce the duties of a person for better productivity and in-depth understanding of a given area.

There are different types of architects. The diagram below lists some of the most crucial types:
Different types of architect

Every kind of architect has specific roles and responsibilities. The following listing will help in to understand the same at a high level.

System architect

  • Helps the team understand the given system from an engineering point of view. 
  • Has in-depth technical knowledge. 
  • Can play a cross-cutting role taking technical & management decisions. 

Solution Architect

  • Provides technology backed solutions for the system or application. 
  • Bridge the system architect and product management or business users. 
  • Participates in the framework or POC / POT development. 

Technical architect

  • He/she is more like a super engineering expert and works very closely with the engineering team. 
  • Codes for key / complex features or stories as part of the scrum team. 
  • Interacts with different team members, participates in deployments and triage calls. 

Product architect

  • Participates in designing and architecting the technology aspects of the software product (one has to be mindful of the difference between custom developed application and a product.)
  • Participates in the framework or POC / POT development. 
  • Interacts with different team members, participates in deployments and triage calls. 

Enterprise architect

  • Plays a crucial role in defining the technology roadmap and ecosystem across the enterprise. (He/she focuses on all the software in the enterprise landscape)
  • Provides strategic (technology) guidance to the organisation and handshakes with business users and CxO.
  • Provides high-level abstracted reference roadmaps to the solution architects. 

Domain architect

  • He/she is responsible for a particular technology domain. E.g. he/she could be a:
    • Database Architect is responsible for designing, engineering and guiding the data store technology.
    • Cloud Architect is responsible for designing, engineering and guiding the cloud (platform) deployment, engineering and creation aspects.
    • Integration architect is responsible for designing, engineering and guiding the integration technology.
    • Infrastructure architect is responsible for designing, engineering and guiding the infrastructure required for the organisation (VM, Containers, Network and so on).
    • Mobile architect is responsible for designing, engineering and guiding mobile development (Native or MAPD).
    • Security architect is responsible for designing, engineering and guiding the security (AAA & Vulnerability) of the system and enterprise. 
    • Performance architect is responsible for making sure that enterprise at large performs as per SLA expectations and guides the engineering team if need be.

Of course, the above definition will vary from one organisation to another. Each organisation will have their way of defining the roles. Sometimes, the functions are clubbed, and sometimes the roles are given different names/titles. But in general, above grouping should hold its ground. 

I am sure, the delivery managers are smart folks, but during a difficult situation, expectations and roles are not always seen within the ambit of defined boundaries. 

Also, I am hopeful that an aspiring architect gets help from the above information and can pick the path with better clarity and with right expectations from the role. 

Conclusion: One architect ain't fits all! 


Stop abusing API by calling it Microservice

Note: Please do not read this article expecting it will help you understand the nuts and bolts of Micro-Service-Architecture (MSA) or API. It is assumed that the reader has a basic understanding of MSA / API. 

The world has been talking about MicroService Architecture (MSA) more than ever before. 

Developing or designing an MSA is no longer an aspiration but has become a mandatory arsenal in the armoury if you want to win the war against the aliens! 

Moreover, in the quest to have MSA, most of the time either the architecture is over-engineered, OR standard interface based architecture gets marketed as MSA. 

So, what is the problem? Our obsession with using the buzzwords OR miss-understanding of the difference between MSA and API. 

In this article, I don't want to talk about what an MSA or what an API is. I am sure there are many articles (excellent ) already available which doesn't make me write about it. 

Hence, in this article - let us focus on how not to call standard API implementation an MSA. 

Application Programming Interface (API) is a generic term we use to describe the interface that is used for exchanging information between two or more systems. These interfaces would be based on HTTP(s) or SOAP or RESTful or RPC or TCP or Socket. 

A standard interface based implementation. 
Moreover, the type of integration can also vary from being structured or un-structured (using queues, socket, database, file-sharing, etc.). However, these are based on standard web or non-web interfacing options. 

The way these interfaces are designed or developed could vary. It could be a collection of domains grouped to form a single API or discrete API, or it would be based on functions, user interface requirements or events. 

Therefore, the term API only describes the interface, the shared language that client and server, API consumer and provider, use to perform the handshake. For the consumer, it is nothing more than a brief about the interface and an endpoint URL or set of URLs.  

Extending the same could result in the architecture to form a service-oriented architecture (SOA). However, still, this is ain't an MSA. 

An MSA is an isolated, self-contained function of a more comprehensive system or applications. Every MSA should have a well-defined scope and responsibility to ideally do only one thing (related to the domain or service). One can consider an MSA as a set of small APPS that have their standard interfaces (API) exposed to the outside world. These interfaces allow them to interact with others. 

A standard MSA based implementation.

Beyond, just being an APP that has the interface, MSA is also designed on the premise of other reliable and stable notions & principles. 

The MSA should have its deployment lifecycle (this is where MSA and containerization relation is much stronger than all), should have its datastore, unique communication mechanism (for inter-service communication, the system would have implemented orchestration using ESB or Queues. 

There is a subtle difference between MSA and API. An MSA could have a set of API, but an API may not necessarily be part of an MSA. 

MSA and APIs are not the same and, while we’re at it, neither are microservices and containers. Hence, the two concepts work together in one way or the other: First, MSA can be a mechanism for backend or an internal, partner, or public API. Second, microservices generally speaking rely on APIs as a language & platform agnostic way to interact with each other in an internal or external network. Development teams can use similar design approaches and tools for creating both outward-facing and microservice APIs. It leads to a paradigm shift in the way DevOps is engineered if the architecture is MSA or just SOA or just API based. 

Hence, we as engineers or architects or designers should be mindful in calling the implementation an MSA based against API based. While we may fancy our chances by advocating 'our' implementation best in class, but that does not mean it has to be based on MSA. If there is a need of highly scalable, de-couple deployment mechanism, containers holding the serverless components, independent development that is domain or data-driven - we do have a good use case to implement MSA. 

Otherwise, in most of the instances API implementation based on SOLID ( Single Responsibility, Liskov Substitution, Interface Segregation &  Dependency Inversion) principles, will work most of the time. 

Therefore, let us be conscious in not calling our "excellent" API based implementation an MSA implementation, just for being cool. We are smarter if got things right for the current and future requirements. 


Need of a T-Shape Developer and an Architect

We as individuals have one thing common. And that thing is "aspiration". We all aspire to grow, be successful, command respect, be knowledgeable and so on. The same is true for an individual who is one of the cogs in the success story of many Software companies. 

The individual in the subject is an engineer. He/she could be a junior or senior or very senior engineer. And as he/she grows in the experience, expectations exponentially grows. 

An engineer who has probably worked as a Microsoft or Java or Database or UI expert is not expected to know it all. Similarly, an architect (a very senior engineer) is expected to know not only around application solutions but also should be able to converse and practice in the space of infrastructure & domains. 

Such individuals are also termed as full stack developers or architects. In this article, we refer them as T-Shape developer/architect. 

As per Wiki, the concept of T-shaped skills, or T-shaped persons is a metaphor used in job recruitment to describe the abilities of persons in the workforce. The vertical bar on the T represents the depth of related skills and expertise in a single field, whereas the horizontal bar is the ability to collaborate across disciplines with experts in other areas and to apply knowledge in areas of expertise other than one's own.

Using the same analogy, a T-shaped developer is the one who has a deep and robust understanding for a programming stack and has broad breadth exposure and knowledge of other ancillary programming stacks. 

E.g. a T-shape developer could be an individual who is an expert in Microsoft.Net (C#) and has a good grip on Angular and Database. 
Such credentials make the developer an end to end engineer who can work on all layers of the software development lifecycle. In this, e.g., the engineer has in-depth C# knowledge (represents the vertical bar of T) and has a fair or good understanding and expertise about Angular and DB. 

For an architect, however, he/she must possess not only in-depth knowledge but also to have broad technical expertise across several platforms. 

At the same time, the architect’s growth directly proportional to the number of platforms in which he/she has academic and mainly practical expertise, and also, with the number of subject areas in which he/she know oats.

While we talk about T-shape developer, the progression starts from the standard vertical bar and goes on to become T-shape to Pie-shape and eventually to an M-shape architect. 

The adjacent diagram represents a time to role graph. As time progresses, the expectations from the role also increase. 

Starting as a developer (represented by an I), the expectations from the individual increases. Apart from the depth of core programming understanding, it is now expected that the individual understands 1+ platforms and domain. And the expectations increase as the role progress. 

Following table can be used as a role to expectation mapping reference:

ShapeRoleExpectations (knows)
IDeveloper1 platform 
tLead Developer1+ platform + 1 domain
TArchitect1++ platforms, 1++ domains, Architecture Principles & Practices
nSr. Architect2+ platforms, 2+ domains, Enterprise Architecture
mPrincipal Architect3+ platforms, 3+ domains, Wide Enterprise Architecture


Smart home coming to reality...

A Smart Home is one that provides its home owners comfort, security, energy efficiency (low operating costs) and convenience at all times, regardless of whether anyone is home.

"Smart Home" is the term commonly used to define a residence that has appliances, lighting, heating, air conditioning, TVs, computers, entertainment audio & video systems, security, and camera systems that are capable of communicating with one another and can be controlled remotely by a time schedule, from any room in the home, as well as remotely from any location in the world by phone or internet.

Most homes do not have these appliances and systems built into them, therefore the most common and affordable approach is for the home owner to retrofit smart products into their own finished home.

Automated  home in India and Automated home solution is a small step to achieve this goal and is becoming integral part of our life. Imagine a single button for you to control. Automated home in India applications not     know all person about its features. Automated home solution now became famous in metro cities in India.

Following are broad spectrum of features that makes home a "smart home":
1 Lighting
2 Curtain
3 Any home appliance control
4 Timer control
5 Temperature control
6 Scene control
7 Streaming of Music and videos
8 Enhance Security
9 Sensors which can trigger alarm in your absence due to Gas leakage or any intruder invasion

Following are essential elements you would want to control:
User Interface
Controlling  Devices
Safety Devices

The big question however is what does it takes to make a home a "smart home". There are many products avialable in the market which are in the forms of KITS or SETS which are as simple as plug and play devices. It will have a central hub through which all the devices are connected and shall communicate. 

Some of these products can be browsed at:

There are many such products and for each product the price will vary based on the features and nodes that are installed. But the cost will range from 15K to 50K for standard kits while of-course the upper limit can go as high as 3L INR.