Organizations are worried more and more every day on facing the technology risk that can come in the form of exposure of data through the 3rd parties and from its own investments in technology to support business activities.
One of the important defense mechanisms to tackle cyber risk is to reduce the digital attack surface that are under our control. This translates into the following strategic objectives for an organization:
Consolidation of Infrastruture elements like VMs, servers etc., in the IaaS segment.
Consolidation of applications by moving to platform oriented software solutions in the PaaS segment.
Reducing the need for re-traning a fluctuating technical workforce by adopting SaaS applications that include easy-to-understand intuitive self-servicing capabilities and which is preferably cloud based, which in turn enables us to leverage the 'Security of the Cloud' paradigm. Because of the 'Security of the Cloud' paradigm, we will be able to transfer a sizable portion of our 'Technology Risk' to cloud service providers.
When it comes to the purchase of software applications that are based on platforms, or when it comes to evaluating the best possible solutions (for example data storage option for the data science team) I am able to see 2 different perspectives.
The first perspective is from the point of view of the software vendor.
There are so many different software products having a wide spectrum of quality attributes (UX/UI, fit-for-purpose etc.,) from good to worse, to solve the myriad of business issues and needs that come in a range of requirements, constraints and designs. Because of this chaotic market, some of the best products fail to make it to the front because of -
Already established 'super-power' product segment leaders that are able to drown the better designed products by leveraging their sheer market presence.
Non availability of resources. Well architected products may need to spend more not only in R&D but also in product marketing, at least initially, and this may be beyond their budget for new innovative companies, as they race against time for survival.
The confusing product specification literatures that use eulogies to exaggerate their functionalities. For example , if a particular technical term like 'In-memory Database System (IMDS)' or 'API Management Platform' or 'Managed File System (MFS)' is becoming popular because of an evolving ground breaking concept, and since there are no common specs published by a central body around these evolving concepts, any software company may use these popular terms in their marketing literatures even while their products are substandard and contains little or no implementation artefacts adhering to the concepts that made these technical terms popular. This makes the life of the genuine software vendors miserable. They are forced to compete on the basis of the marketing power and not based on their technical soundness of their products. This, sometimes leads to the situation where the genuine software vendors have to drop their prices to absurd/unaceptable levels. They, perhaps, silently suffer till their company reach a critical volume in their business.
The second perspective is from the point of view of the software buyer.
The buyer is driven by business objectives and financial objectives and is often times lack the needed time or the situation is made urgent by an imposing new regulation having an organization wide impact. The change management including training, roll-out and adoption are a night mare to handle.
2. Under these driving business conditions, the CIO/CTO/CISO/CFOs have to decide upon the purchase of software applications that are the best-fit while keeping the CAPEX/OPEX low. They probably go by the references provided by their network and/or partly influenced by the popular product research reports (which are also many in number) or go by the recommendation of consultants from the big 4 or their largest system integrators! These options are driving from their trust on their sources and not from well researched purchasing initiatives with strategies like 'Evaluate atleast 3 vendors before deciding'. These options may work or may not work and if it fails you may not know the real reason why it failed. If these products are implemented 'successfully' then, you may have trouble in identifying the degree of success of a product which is not fully evaluated by yourself.
3. The same proliferation of marketing literatures mentioned above, may cloud the minds of the software buyers. They become afraid to select or pause !
My recommendation is for the companies to hire world class enterprise architects(EA) (please refer to my article on 'Enterprise Architecture' in the technology section of this blog site) and align them group-wise/BU wise/functionally but reporting to a central core architect group. A technical team (with EAs and a core architecture group) which is fully ware of the parent company's business context and which is home-grown can become a great asset in managing the technology risk.
These EAs should guide the purchasing apex CxO offices, BUs and the procurement division in evaluating the software products on the table on a sound technical basis and on the 'fit-for-purpose' basis, while considering the strategic objectives of the company and the plans for realizing the immediate and long term business objectives.
This selection process should be well designed and mistake-proofed. This process should be proactive and thus it should avoid time-pressure on the business that comes due to technical evaluations or implementations. The EAs and core architecture teams are expected to research well and build their technical/architectural prowess and software skills besides knowing well the domain in which thier company operates. They should be particularly be well aware of any new technical break-throughs that can cause business disruptions to their parent company. Like I said in the earlier EA article, each of the business teams then should be focussed on their core busines activities and business/operational risks and should be able to delegate the whole of the technology risks to the EAs and the core architecture group. These EAs should either directly or indirectly manage the operational, technology risks (IT/cyber risks/data privacy risks/infosec risks etc.,) of their associated BUs and relieve the business out of these wories.
Nevertheless, the business should have its own processes to evaluate the financial/performance/ compliance metrics around the technology risk as a whole, which will then indicate about the effectiveness of the EA/core architecture groups and may guide them in course correction.