I have been reading up on ways to go about enterprise architecture. A few links later, I stumbled upon a well-explained article from Microsoft on the same (link below). While there are several takeaways from that excellent write-up, I decided to put my own spin on one of the most important things the author spoke of: prioritization. Why is that most important thou asketh…
Having seen some rounds of enterprise architecture implementation furthered by the very commendable efforts put forth by both organizations and their technical partners, prioritization for me emerges as an important activity. The reason for that is, it makes things simple and plannable. Digestible, too if you will. The complexity that we deal with today is nothing short of behemoth even for a traditionally mid-sized firm. There are staggering amounts of data, integration points and dependent systems which makes analyzing and predicting them all the more difficult.
For example, consider a HR System that reads the attendance of a biometric hardware. The system’s data is utilized by Payroll and Project Management systems for their respective duties. The types of data a HR system can receive (for a simple scenario) are ‘employee present’ or ‘employee absent’. Two states so far, which is pretty simple. The Payroll system, depending upon the investment options selected by the employee can either reimburse the full salary, deduct taxes (where there are several, several possibilities) or reimburse salary and coupons as well or all the above. Hope I am not losing you there. But even if I am, that just says how complex things can get even with this super-simplified model as well. So we have four possible states of data from Payroll. Depending upon whether the employee is present or absent the salary can assume some corresponding states (ignoring business travel, paid leaves, maternity leaves and so many other possibilities). How many? Three multiplied by four is twelve states. The complexity keeps on multiplying when more and more states keep getting introduced in the mix. With another three or four states you get around fifty possibilities. That is still alright, but with all real-world considerations, the number won’t get any simpler anytime. This may be a very rudimentary example but I hope it tells you that an enterprise architect planner has to oversee a LOT of things to start rolling out a new or changed architecture.
The reason why many a rollouts are mired in confusion, overshooting budgets and royally bombing project plans are because of… well many things. D’oh! But today we are looking at prioritization. How does the organization decide what items to take up first and roll out? Should we go for an in-depth processing first or should we look at getting something of value out there first? The latter is much better since results always get a buy-in from stakeholders. Completed assignments always enable us to do a retrospection and plan better. Projects that stretch can be educational too but it will be difficult to take a step back mid-way through and get to know of things that may be going wrong. So here is a bit of strategy to know what things to focus first for your enterprise architecture.
- Perceived Value – If a project’s perceived value (not ROI, not bottom-line impact, but the value that others believe in) is more, it is a good thing to prioritize.
- Visibility – A project that is more visible and can possibly invite more opinions is also a good one to start with. You may ask, what if such a project is very costly and risky?
- Cost – Always aim low! I never thought I would say that but this makes a lot of sense for implementing this. Low cost projects are the best to learn and grow from so that the higher cost ones are done better.
- Risk – Again, aim low. Low-risk projects get approvals, and if things go south, you not only apply the learning, but also the management is not left with an unforgettably bad taste right at the start.
- Measurability – I have seen that sometimes, a large amount of good work gets done in the way of implementing an enterprise architecture, but when people ask, ‘So how are we better off with it?’ the answers don’t seem very concrete. That is not good. If someone questions your first project item that you have taken up, showing a measurable positive impact of it helps you continue smoothly, unabated.
- Time to Completion – If you can finish faster, take it up! You can learn quickly, be nimbler in implementation and go for the progressive bang (as opposed to the big one) later on.
The above criteria have not been stated in any particular order. They are all important considerations for prioritizing enterprise architecture implementation. So how, you ask, should we choose based on all the above considerations?
This is where I am going to use a diagram that the Microsoft article also used. A circle where all of the above have been shown to represent sectors.
As we see in the circle we have three zones of indication, positive which means the given parameter is favorable (based on the stated arguments), neutral which means the estimated value of the parameter won’t raise eyebrows or cause much impact and of course, negative which we have to look out for. The circle is marked all around with the parameters we just saw. So let’s apply what we have seen!
The Microsoft article goes on to give an example where we have to choose between implementing a ‘Single Sign-On’ versus a ‘Customer Accessible Knowledgebase’. You can read the parameters-list again and have your estimated values in the circle ready. This is what the article notes the circles to look like after comparing the projects:
I think this is pretty accurate. Single sign-on, comparatively speaking, will take longer and won’t be visible and will carry risk (because of the kind of credentials-data involved). It is measurable, yes and its value if also perceived. But if you look at the Customer Accessible Knowledgebase (or a Knowledge Management System as some like to call it), it scores better on everything. Not only will take up less cost and will be faster to get done, but there will be something to look at and play with (measurable value, perceived value scoring high hence). The visibility is there and the risk is also low. So between these two, you know what you are going to pitch the management with!
There is one other thing that the article did not speak of which I think plays a role too. The desire to impress and win-over management by implementing something difficult and messy is sometimes a driving force. ‘So what if single sign-on is tricky and time-consuming? My team will get it done in no time and we will show them how it’s done!’ Well, that doesn’t augur too well for a larger victory, which is sort of the point when it comes to enterprise architectures. It is always important that we do things progressively and manageably than warring with beasts we never had the time or resources to understand.
Well that’s it for now! Hope you liked the idea of prioritizing and will pull a page or two for your own or your customers’ implementations.
Source of diagrams: https://msdn.microsoft.com/en-us/library/aa479371.aspx
