Defusing the decision bomb
Decisions! Decisions! Decisions!
We’ve all been at the juncture where we have actively struggled for making decisions. It is not easy, never easy and no silver bullet exists! It is almost the single most hardest thing ever, especially in the creative technology space or software business!
As a Software Architect, this is the most difficult aspect of the job that I am constantly mulling over, going back and forth, to find the right balance, to understand the 360 view; to make a DECISION.
I am 100% convinced that many have heard this, so hear me say again — Don’t try to make anything that you are working on “perfect” and don’t try pursue perfectionism, instead pursue “progress”. Know that the time is now and you are acting on it now hence the decision is needed now.
Not to confuse you more but want to set the context; below are some dilemmas that we are having in this tech age which has vast impact on our lives and the way we create software, hence decisions are very important
To NoSQL or not? To adopt Domain driven design or not? To Microservices or not? To containerize or not?
Here are some of the aspects of the data points that you need to consider while assessing any solutions to help you make the decision process more easier. One needs to really be engaged with this in order to make a quick turn around when making decisions, especially if you are an Architect as the project might depend on it.
Brainstorming Decision making mind map
As with everything else, some sort of brainstorming is needed to start with and this applies even to the Decision making process and what simple way to accomplish that with a simple mind map. The following mind map will give you the pointers for the Decision making process and what is involved in it.
Technical analysis with Pros and Cons
Often this starts with asking the questions — right or wrong; always depends upon the context. There is no one method to perform Technical analysis and viability of adopting something. One way is doing that is Proof of concept and there might not be a way to find Pros and Cons and any other implication it would having to do that.
Understanding, documenting and listing the Pros and Cons are very important, which will give a clear indication and steer on your decision making process. Collecting the facts and dissecting it and laying out in a simplified manner will help you make the informed decision and is an exercise that would need to be refined overtime. Along with this, a recommendation would also be helpful for the teams to understand the way it was evaluated and arrived at.
Non Functional requirements
If you look up for this, you’d get tons of information and examples as to what are differences between Functional and Non-Functional requirements. But this is actually is simple than you think it is, in a lot of cases. In developing software, there is a thin line between a capability or feature that you need to develop and any non-functional work that you have to do in order to support it. This is actually a controversial topic when reviewing requirements because they don’t necessarily have to spell it out.
An example might be that, from a Mobile app, I need to submit an order form which is based on a template that the app already has but there is a possibility of that template being changed by someone at the back office. In which case, an alert needs to be sent to the Mobile app so that they can retrieve a new template of the order form which may constitute to the nature of the information that needs to be filled out. While the functionality of how the Mobile app should behave and react to the alert may well be capture within the requirements, it is not necessary that it will contain how the alert should be managed and what sort of architecture it should adopt and if it should have the capability of handling the alerts when the device is offline etc.
Resiliency / Self healing
the capacity to recover quickly from difficulties; toughness.
the ability of an app to recover from certain types of failure and yet remain functional from the customer perspective. Resilience is how you achieve the outcome.
This is a trick one, since it is suitable to the Infrastructure and also to how we create software with resiliency built into it such as error handling and re-processing failures either through cron jobs or automatic processes. Potentially, those failures that you are concerned with must be logged somewhere (i.e. a dead letter queue) which provides the visibility of those issues that you can deal with and treat accordingly.
In the modern applications, this is becoming a paramount need since no organisation can afford missing the boat of “now” and might also add, speed is the key here and you might be looking at the missed window in which your application could have done better. Needless to say, whatever you decision you make, at least make sure they support the need of being resilient.
Platform requirements
Now that we have done the creative and implementation bit, we need to understand how this will be deployed and what sort of Devops the platform might support and how the Performance counters are. For this, you need to thoroughly understand platform capabilities, their Service Level Agreements, Limitations and Cost. These are major factors in the decision making process in which if the Application does not have expected ROI then it might over exceed the platform / infrastructure cost hence proving to be risky even before you reach a decision.
This is also different to the on-premise v cloud solution and also depends upon the vendor. If you choose to go with Cloud solution, then weigh in all the options and evaluate what kind of service you’d need for the nature of your Application or Service. Essentially, this would need be handled by your Devops team so their buy in and expertise in a achieving good cadence is crucial.
Phased Approach
A phased approach to implementation is a crucial element of a successful implementation strategy because it helps overcome resistance to change, allows lessons learned in early phases to be incorporated in the systems installed in later phases, and ensures that a solid foundation of project-level data is available prior to rolling-up enterprise-level information.
Finally, deliverables are the ones that really matter; it carries the weight of the outcomes of the activities carried out based on the decision.
You might have outlined the perfect and ideal solution but it might take several steps to get there. To achieve this, you might decide to take a phased approach with architecture supporting the same all the way to the end. In this approach, you outline what you’d achieve in various phases.
But remember, at the end of each phase, there has to be a meaningful deliverable that has to add value to the feature set and benefit the Customer. Regardless of green field or brown field project, this also depends upon the requirements, hence a problem/solution approach as a brainstorming exercise would help nail down the complexity and how one would break down into workable, practical deliverables that is accepted by all the stakeholders and parties involved.
In Closing…. Defuse with Affinity
Though the decision making process may some time be mayhem and lead to astronomical design changes, you have to be cognizant that you reached a decision and for a reason. You have to adopt the approach you evaluated and applied for a specific decision with profound affinity. Bottom line, it is your decision and make it count every step of the way. It is a process, so hands up if it fails and give yourself a pat if it worked!
