Skip to main content

‘Customers & Vendors’ Maturity Level

In these days of business where we are living in the world of various maturity models to measure the maturity levels of SOA, software capability etc. I am seeing maturity level from a different perspective.  

As the need to build highly available & scalable systems is growing high day by day, unless there is a reasonable level of maturity that exists both on the customer side and vendor side, it is tough to meet the goals.

Here, by the word ‘Maturity’, what I mean is awareness and knowledge on the factors like best architectural / design practices, non-functional requirements, QoS requirements, industry standards and their direct impact on the business, based on a business domain, industry and operational nature of the system

Some customers are matured enough to clearly specify their ‘Scalability’ & ‘High Availability’ requirements more precisely than others. Some of them will specify it just for the name sake and if a vendor asks do you want high availability, customer then will simply reply “yes, we want”. But, in reality they may not aware of different levels of availability that exists (99.99, 99.999, 99.9 etc.) and what type of implication each one have on infrastructure planning, development & testing life cycles, cost etc.  If a customer has a maturity, he/she will also know what level of availability would suffice their business and how much it would cost.

In some cases, a matured vendor will know what level of impact a customer’s demand would have on his project schedule and budget. If a vendor lacks maturity, he will simply accepts whatever a customer demand in terms of QoS requirements just to get the project!

Lack of maturity on both sides will result in a disaster!

Matured customers will be more precise in all their requirements. Depending upon their level of maturity, they will document their requirements in addition to their functional requirements. Some customers even specify their requirements on cross-cutting concerns very clearly. They will be more specific about logging, instrumentation, exception handling etc. For these types of customers, the final system will meet the objectives, irrespective of the type of vendors they are dealing with. Even if the vendors lack knowledge on best practices, industry standards, architectures etc., as the customers are very specific in their functional, non –functional and cross-cutting concerns related requirements, entire development will be driven in the right direction.

Imagine the case where an immature customer dealing with an immature vendor. It is like a blind leading a blind. In this case, customer would have documented the functional requirements very well. But, he/she would not have specified any other thing explicit. In this case, if the vendor is matured, he would have educated the customer on the significance of non-functional /QoS and cross-cutting concerns requirements. He would have also made customer aware of the consequence of building a system without giving due weight-age to those factors. Take for example, an immature customer ‘A’ wants to build an e-commerce portal by a mature vendor ‘B’. In this case, even if the customer has not specified anything explicit about high availability, the vendor would have conveyed the customer about the importance of high availability, its different levels and its impacts on the business. Vendor would have educated the customer that if their web site is not build for at least 99% high availability, web site may not be available for so many no. of days in a week and in that time, online buyers cannot make orders. So here, the customer would have realized immediately the importance of the high availability and opted for it. So, the outcome of a system depends on the maturity of both the customers and vendors. Unless any one of them has a reasonable level of maturity, their partnership will not result in a system that meets its objectives.

Comments

Popular posts from this blog

Lambda Architecture on Microsoft Azure

Gone are those days when Enterprises will wait for hours and days to look at the dashboards based on the old, stale data. In this fast world of BYOD, fitness gears and flooding of other devices, it is becoming super important  to derive out “actionable” information from huge volume of data / noise that is generated from these devices or any other data sources and act proactively on them  in real-time, to stay competitive.

At the same time, the need for having dashboards and other analytical capabilities based on the quality, cleansed, processed data still very much exists.

With the emergence of more data types and need to handle huge volume, shift is happening from the conventional data warehouse practice to cloud based data processing & management capabilities where high volume batch processing is possible at the optimized cost. Business scenarios demanding the need to process the data in real-time   More

SharePoint 2013 Architectural Trade-Offs

When planning for deploying SharePoint 2013 based Enterprise workloads, it should be done with the consideration / awareness of impact of various architectural decisions what we make. As SharePoint 2013 is a flexible platform providing lots of options in terms of configuration of the existing OOB features and development of custom development solutions to address specific business functional needs, care should be taken when making a particular decision and its impact on overall solution. Even though SharePoint is a matured product, the effectiveness of various business capabilities such as Enterprise Social, Enterprise Search, BI, Document Management, Web Content Management, and Enterprise Content Management that will be delivered based on it, in terms of addressing the business requirements depends on architecture planning. Effectiveness here means performance, security, up-time and other architectural qualities like Scalability, Reliability etc. more ...

Heterogeneous Cloud Integration

Heterogeneous integration is common scenario in the Enterprises where their IT portfolio is based on heterogeneous platforms. Various solution approaches such as message broker, messaging middleware, SOA – service based integration were employed to address heterogeneous integration challenges.

These solution approaches were good when the integration happens on premise, with in the data centers of an Enterprise. Problem here is non-availability of “elasticity”.

With the Enterprises started leveraging cloud platforms extensively for various solution aspects such as elastic computing, storage, it opens new capabilities that can be leveraged for heterogeneous integration. Also, similar to existing on premise scenario, Enterprises are also leveraging multiple cloud platforms to address their business needs. This scenario will pose same integration challenges as those that were faced within on premise datacenters

Within datacenters / on premise, integration products were expected to comply wi…