company management

What Happened to Good Ol' Competition - Is Innovation Dead?

What Happened to Good Ol’ Competition – Is Innovation Dead?

 

Back in the day, not too long ago, there were many companies competing in a specific marketplace for customers, not consumers. The customer was always right. Companies valued customers. Competition made services and products attractive to customers, and they flocked to the companies that not only provided the best products, but also the best customer service.

Today, customer service is a distant memory in many cases. A customer is no longer treated as valuable, but instead has transitioned into a consumer. Consumers have been deemed a company right. In multiple ways, innovation has taken a back seat. There is a pervasive herd mentality. Instead of different thinking and innovation, too many companies follow the crowd and conform. If companies don’t conform for whatever reason, litigation becomes a significant obstacle for nonconformists.

Companies become more powerful through acquisition by creating industry specific oligopolies, or a monopoly as opposed to the good old days of competition (Circa the advent of the Internet). Increasingly, today’s competition is wrapped up in patent trolls, and licensing litigation. Competition seems to exist only in sports and politics (if we believe what we see is true). The business world has seceded from the world of competition.

This article is not intended to point a finger at any one company, but to highlight a development in the business world that crosses industries, and detracts from innovation and unadulterated competition.

We need to consider how best our global future can be served by restricting new ideas and experimentation from those of us who have much to contribute. Should monopolistic behavior and litigation serve as the backbone of the business world in the 21st century, I think not.

http://wp.me/p2MYVz-sI

Booker Showers

How to Manage Business Processes Using Facts

How to Manage Business Processes Using Facts

Effective decisions and appropriate actions result from high quality, complete information. A system built from the ground up with a single purpose (to integrate) can profoundly affect the way a business operates. Integration dissolves barriers to communication, reveals opportunities for revenue growth, and helps reduce or eliminate expenses.

A significant operational challenge lies in identifying how to help employees perform tasks better, and faster, using fewer resources. How to Manage Business Processes Using FactsHowever, today’s internal systems are growing exponentially while becoming more fragmented. Extreme difficulty is developing within organizations to create a clear view of the business. A real-time view for large organizations is impossible because management only receives small bits of information from disparate systems that require business analysts to interpret. The disparate systems must connect to create a complete business view. A business does not effectively operate without the facts that represent a true understanding of the business and its challenges.

An important determination often overlooked when a company adopts a new system is “will the system play well with others.” Too frequently, a new system does not play well with existing systems, which is why integration should be a vital part of any IT strategy. To enable a company to run like a well-oiled machine, the parts must move in complement. When one part moves, the other parts should produce complementary reactions.

Large organizations usually suffer from departments operating as silos instead of functioning in information-sharing, reciprocal ways that benefit the entire organization. Staff invest considerable time  gathering information within various departments to create reports to present to Executives. The information gathering process is time consuming, prone to errors, and often information is outdated by the time Executives are informed. Consequently, management will make decisions based on guess-estimates, and gut feelings instead of real time facts.

Don’t leave system integration out of your management strategy. Yes, system integration is IT focused. Nevertheless, a clear understanding of an entire organization is only possible when system integration is considered a vital component of business process effectiveness.

REST as Template Services

Template ServicesCompany management consistently struggle with exposing internal products as REST services. There is a lack of balance between organizing internal products to be used in combination with other internal products (to create a new type of service) and REST principles.  Understanding the difference between controllers and REST resources will eliminate confusion and misuse of fundamental REST principles.

Previously explained, REST is best used for static objects that Create, Retrieve, Update, and Delete  (i.e., the HTTP equivalent POST, GET, PUT, and DELETE). If the service acts as a function, consider designing the service as a REST controller (see How to identify objects as REST Controllers or Resources). Otherwise, the service is data.

The ultimate REST architecture is a service structure that combines with other REST services to create a totally new service as depicted in the following diagram:

A Powerful REST Architecture that Focuses on Monetization

REST Template Services

The platform is the application, or system exposed to external developers. Platforms are used individually or with other Platforms to create unique services.

The service template defines configurable attributes of a platform. The service template is used to create a service, which has commercial value to an enterprise or an independent developer.

The service variant is a configured version of a service template.  The service variant is an item with the necessary configuration to provide value to a developer and supports necessary provisioning actions.

An offer is a bundle of services exposed via an API, which consist of one or more service variants, offered to developers for consumption to create applications.

In summary, when creating a REST architecture remember one internal service can be used with another to create a completely new API.  Try to stay abstract. Do not release a finished product as a REST service by pointing the URL to the product. When a finished product is used as a REST service, a developer has no options to consume the API.  Separate data as resources and actions as controllers.  Nouns vs verbs.