When you are building a company, there is a famous analogy – either you build a solution that acts like a pain-killer tablet, which means it’s a must have; or you build a vitamin tablet which is a nice to have thing. To simply put, it’s as simple as “Must have vs. nice to have”.
Every business should carefully consider what they are building. In general, the more you align your product with a pain-killer mentality, there are more chances of success. When someone is suffering from pain, it’s most likely they will buy a pain-killer to get relived. Whereas when you build a product with a vitamin tablet mind-set, they might buy if they have extra cash to spend.
In my opinion, it will be very hard to build a product that will just solve the pain-killer issues. It will also be inevitable that the product will also have features that are nice-to-have and complimentary. Sometimes, certain vitamin features may be pain-killers for some segment of the audience. For example, if you are a normal person, eating a vitamin tablet may be nice to have, but if you suffering from vitamin deficiency, then it becomes a must have. Correlating this in software terms, if your team doesn’t have the skill set to know something in-depth, then a feature that abstracts and eases that work will look like a vitamin for an experienced person and a pain killer for an in experienced person.
, whenever we pick up a feature to build, the first thing that we do is to evaluate it and decide whether it’s a pain-killer or vitamin feature. Let’s take five key features in BizTalk360 and see whether it’s a pain-killer or vitamin.
Security: User Access Policy/ Governance and Auditing
One of the core feature in BizTalk360 is the security
capabilities that allows a fine grained control of who can access which part of the BizTalk Server Environment. When the user performs actions like restarting a host instance, terminate service instances etc., it audits all the user activities.
This feature will fit in the pain killer category since majority of the companies would like to have control of who has access to their production environments and keep track of what activities they are doing. Especially when you have a larger team, or your industry (ex: Healthcare, financial sector and so on) forces you to have some compliance.
However, in some scenarios, this feature can be treated as unnecessary or a nice to have (vitamin). Imagine if you have only 1 or 2 people in your team doing some basic in-house integration work. In this case, you are probably less worried about user access/security.
Monitoring and Notification
The next big feature in BizTalk360 is the ability to monitor the health of various BizTalk artifacts
like Receive Locations, Send Ports, Host Instances etc., and alert someone if they are not running in the desired state. This feature of monitoring the health of your BizTalk environment in general is 100% a pain-killer. Whether you have a big or small team, you have invested your time/money in building a solution and your expectation is to make sure the solution is working all the time as expected.
There may be certain features inside the context of monitoring and notification that could be treated as nice-to have or vitamin. For example, Monitoring Dashboards. You can live without them, but by doing so, you’ll miss the visibility aspect of seeing the overall health picture. However, as long as you get email/SMS notifications, you may just be fine.
Web based Access
One of the key value proposition of BizTalk360 is the web based access
to your BizTalk environments. BizTalk server ships only with MMC based BizTalk Admin console. This feature alone may not sound like a pain-killer. Because you can live with the standard MMC BizTalk admin console and manage your day-to-day activities.
However, this vitamin feature in BizTalk360 will become mandatory to support some of the pain killer features and eventually become a pain killer. Example: With out providing a web based access mechanism to your BizTalk environment, it may not be possible to build some dependent features like Advanced Event Viewer, Topology diagram, dashboards etc.
Knowledge Base Repository
BizTalk360 allows you to write and associate a knowledge base article to majority of the problems
that happens in your BizTalk environment on a day to day basis. For example: Suspended service instances, events getting logged in Windows event viewer, ESB toolkit registered exceptions etc., I’ll personally classify this feature as 100% must have (pain-killer) feature. There are tons of benefits for pretty much any sized team/company by using this feature. Over a period of time, an individual or a team can accumulate wealth of knowledge base articles and associate with pretty much all the problems they are facing on a day-to-day basis. This will help the individual or the entire team in solving the problems in a faster way.
Throttling is one of the technically complicated subject in BizTalk server. It allows the system to slow down itself or adjust it’s pace when underlying connected systems are not performing well. Due to the nature of the complexity, it’s generally harder or it takes a longer period for someone to learn about how throttling works under the hood in BizTalk environments. We have addressed this problem using a feature in BizTalk360 called Throttling Analyser
. It’s a game-changing feature, but possibly it could also be just a vitamin. Lot of companies do not care too much or do not justify that kind of mission critical load in their BizTalk environment. In those cases, they treat the BizTalk environment like a black box and need not really worry about how BizTalk handles throttling.
From the above points, you can understand it’s really hard to justify a feature simply as pain-killer or vitamin. In majority of the cases, you just need to go with a gut feeling. Sometimes, luck may be in your favor — the feature that you thought may not add too much value might turn into a game-changing feature, and in some cases, the vice versa could happen.
In general, we try to understand the value proposition of each feature and pick the ones that are more close to solving customers real pain points, rather than building nice to have ones. Most of the time, the feature that solves the customers real pain point will be boring and technically “not so complicated” type.
The general bottom line of this blog post is “Do not create a solution and look for problems
”. Do it the other way – “Find a problem and come up with the solution.