Stakeholders – THE GOOD, THE “BAD” and THE UGLY

If you have been a C-Class executive, Project Manager, Financial Analyst, CIO, in Middle Management or even among the IT developer community, I am quite sure you must have heard the word “STAKEHOLDER”.

STAKEHOLDER, as per business dictionary:

– a person, group or organization that has an interest or concern in that organization

And as per Merriam-Webster dictionary:

– a person or business that has invested money in something (such as a company)

– a person who holds the money that people have bet on something and then gives it to the winner

So, in a nutshell, stakeholders are the entities that can either affect or be affected by the organization’s actions, objectives and policies.

As we all agree that not all stakeholders are equal, there has been numerous attempts to classify them. Different groups over a period of time have come up with their own way to toss around the trendy buzzword to suit their purposes. Some of the commonly heard classifications are: Employees & Customers, Board of Directors, Partners, Stockholders, Funders & Donors, Internal & External, Primary & Secondary, Direct & Indirect, etc.

This can keep going on almost endlessly. What’s the point? How does this help? With such a huge list, it has merely caused confusion and diluted the relevance at the same time. Thus, following the principles of simplicity, my personal choice of classification will be:

GOOD,

“BAD”, and

UGLY.

GOOD stakeholders are entities that are committed to the survival of an organization, irrespective of how they are classified. They strive to be a positive influence and are the committed winds for the sail of an enterprise. These are entities to be preserved.

“BAD” stakeholders are people or groups that have a reason, purpose, desire or the potential to challenge the functioning of an organization. Again they can be anyone. They generally act as a reality check and introduce hard truths that at the end of day help enterprises make tough decisions in the right directions. “BAD” are key players and should be kept around.

UGLY stakeholders, are self-centered opportunists whose sole purpose of engagement with an organization is egomaniacal. They hardly bother to understand the purpose and reason for the existence of that organization and they linger until their self-interests are served. Again, they are widespread and can be found in every group: employees, customers, shareholders, stockholders, partners, etc. They should be watched, avoided, discarded or kept in check. They are the ones who have the potential to make a huge organization fail.

The history of the rise and fall of large (even ginormous) organizations can be very clearly seen through the glass of GOOD, “BAD“ and UGLY. The emphasis of organizational culture has been an attempt to eliminate the sanctimonious use of the word Stakeholder and to especially help distinguish the GOOD from the UGLY, but this has been very confined to the Employee group, which is not sufficient enough.

So, next time when you are up to the challenge of understanding your stakeholders, remember THE GOOD, THE “BAD“ and THE UGLY.

Middleware – Past, Present and Future

PAST:

The true roots of middleware can in fact be traced all the way to the formulation of the client–server model in the 1960s and 1970s, when computer scientists at Xerox and Xerox PARC came up with the concept of server-host (or serving host) and user-host. The fundamentals of this were pretty simple and still hold true:

Servers are a dedicated single or group of systems/machines that are meant to perform certain commonly used generic functions.

Clients are a group of distributed consumers (again systems/machines) that need to avail the services offered by servers. Clients are supposed to make requests and the server is supposed to serve it.

The Client-Server model was a big leap in the history of computing; now the clients are no longer just a dump display terminal to translate and display the byte of data stream from centralized systems (like mainframes and AS/400) into a human readable language. Clients started to take the shape of powerful computing local devices that now would rely on servers for specific needs only. If we look closely, clients have evolved from dump terminals à desktops à laptops à handheld devices (table / mobile) à wearable gadgets.

This model introduced the need for communication channels through which these machines could talk to each other. The history of the term middleware, going all the way back to the 1980s, primarily focused on fulfilling the network connection management software needs of the client-server model. It was not until the 1990s when middleware started achieving sufficient penetration and visibility with the advancement of network technology. The past of Middleware is very well addressed in an article from David E. Bakken, Washington State University. A few of the lines are quoted below:

By 1990s middleware had evolved into a much richer set of paradigms and services offered to help make it easier and more manageable to build distributed applications.  The term was associated mainly with relational databases for many practitioners in the business world through the early 1990s, but by the mid-1990s this was no longer the case [1,2].  Concepts similar to today’s middleware previously went under the names of network operating systems, distributed operating systems and distributed computing environments. [For further reference, entire article link can be found at: http://www.eecs.wsu.edu/~bakken/middleware.pdf ]

In a nutshell, the following diagram to a large extent reflects the past of middleware.

Image1

PRESENT:

Middleware today implies integration servers like EAI, SOA, ESB, Web Services, RESTful APIs, JSON and various others. What really constitutes the boundary of middleware is debatable in today’s world, and the only common settling ground is: a “glue” technology required to integrate diversified systems, components and applications.

Up until today, various vendors have focused on addressing three main areas under the umbrella of middleware: Communication, Processing & Store. So there is no need to be surprised when you come across terms like Middleware for data, BPM, distributed database, and Enterprise Service Bus (ESB), APIs, SOA, ETL, EAI, etc. as a middleware offering. Also, there always has been debate around how one is better than the other and as the IT landscape changes or evolves, how one will survive and grow at the expense of the other. Different vendors with different focuses have their own story to tell. At the end of the day, all these are good enough to confuse everyone about this mystic term called “Middleware”.

Today, Oracle is the only organization with the most holistic and all compromising approach towards Middleware. Middleware is a platform and not just diverse sets of framework, technology or integration offerings; it is the software layer that lies between the operating system and the applications on each side of a distributed computer network (quoted from Oracle Middleware Concepts Guide). The following image from the same guide on Fusion Middleware reflects this holistic approach very well.

http://docs.oracle.com/cd/E21764_01/core.1111/e10103/img/productoverview.gif

The Platform is indeed the present of Middleware and there is no doubt every vendor in the near future is going to follow the same suite.

FUTURE:

What does middleware have to offer in the future? Is Middleware as a platform the end of the Middleware evolution?

Indeed the answer is NO.

EVOLUTION is the special gift that has been bestowed on all living creatures and then extended through their innovations. We have not stopped evolving and we never will; so it will be with middleware. Now the question comes, what’s next?

The 21st century has witnessed ongoing increasing dependency of business on technology. At the same time, it won’t be incorrect to say that technology has seen tremendous unimagined growth and adoption because of growing business needs. So, the answer lies in the very basic question, how can Middleware be a business accelerator of tomorrow?

Will it be in the technological improvement of HUB-SPOKE over POINT-TO-POINT, SOA over ESB, RESTful over SOA? Middleware is the behind-the-scenes mechanism that enables distributed, diversified technology to stick together, but that will not be sufficient enough for future solutions to cater to the growing needs of a business. One thing is for sure, that no one technological approach is going to triumph over the other in order to fulfill the needs of an entire enterprise. The future of middleware has to be based on a hybrid technological model that will need to be business centric.

In short, Middleware has to follow the evolutionary path of human communication skill. Middleware as a platform is still very primitive when we talk about efficiency and effectiveness of communication, compared with what humans have mastered so far. Middleware communication needs to develop receptive language skills.

For the Middleware of the Future, the technology glue has to be Simple and Smart, with flexible advanced skills to speak and comprehend any business language.