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.


The wonders of Mind Mapping!

Mind mapping is one of the best ways to capture your thoughts and bring them to life in visual form. Beyond just note-taking, though, mind maps can help you become more creative, remember more, and solve problems more effectively. Whether you're new to mind maps or just want a refresher, here's all you need to know about this technique.

A mind map is basically a diagram that connects information around a central subject. I like to think of it like a tree, although it has more of a radial structure. In any case, at the center is your main idea, say, poetry, and the branches are subtopics or related ideas, such as types of poetry, famous poets, and poetry publications. Greater levels of detail branch out from there and branches can be linked together.

Mind maps can be more effective than other brainstorming and linear note-taking methods for a number of reasons:

Think of it this way. Imagine you were asked to write down as many uses for a brick as possible. Many people would just start listing all their ideas (building a wall, building a walkway, etc.). But what if you started from a broader perspective, such as thinking about the properties of a brick. It's heavy, so you could use it: as a paperweight, to hold down a garbage bag while raking, as an exercise weight, to grill juicer chicken, etc. It's also thick, so you could use it to prop up a planter or as a doorstop. It's red, it's hard, it's rectangular, etc. That's the magic of mind mapping: Once you start, the possibilities seem almost endless.

It's a graphical tool that can incorporate words, images, numbers, and color, so it can be more memorable and enjoyable to create and review. The combination of words and pictures is six times better for remembering information than words alone.

Mind maps link and group concepts together through natural associations. This helps generate more ideas, find deeper meaning in your subject, and also prompt you to fill in more or find what you're missing.

A mind map can at once give you an overview of a large subject while also holding large amounts of information.

It's also a very intuitive way to organize your thoughts, since mind maps mimic the way our brains think—bouncing ideas off of each other, rather than thinking linearly.

You can generate ideas very quickly with this technique and are encouraged to explore different creative pathways.

  • Start in the CENTRE of a blank page turned sideways. Why? Because starting in the centre gives your Brain freedom to spread out in all directions and to express itself more freely and naturally.
  • Use an IMAGE or PICTURE for your central idea. Why? Because an image is worth a thousand words and helps you use your Imagination. A central image is more interesting, keeps you focussed, helps you concentrate, and gives your Brain more of a buzz!
  • Use COLOURS throughout. Why? Because colours are as exciting to your Brain as are images. Colour adds extra vibrancy and life to your Mind Map, adds tremendous energy to your Creative Thinking, and is fun!
  • CONNECT your MAIN BRANCHES to the central image and connect your second- and third-level branches to the first and second levels, etc. Why? Because your Brain works by association. It likes to link two (or three, or four) things together. If you connect the branches, you will understand and remember a lot more easily.
  • Make your branches CURVED rather than straight-lined. Why? Because having nothing but straight lines is boring to your Brain.
  • Use ONE KEY WORD PER LINE. Why Because single key words give your Mind Map more power and flexibility.
  • Use IMAGES throughout. Why Because each image, like the central image, is also worth a thousand words. So if you have only 10 images in your Mind Map, it’s already the equal of 10,000 words of notes!

There are many tools (free and paid) available that offers mind mapping. You can find the entire list here

However my favorite tools are MindMeister and MS Office One Notes.

One of the map that I created, can be found at

The map is all about what cloud computing is and the way I represented the same in form of Mind Map.

There are many sample maps available which can be explored to get some ideas. Hope you enjoy this way of putting the thoughts and remembering the same.