Functions Required in the Cloud PaaS Layer to Support SOA

The Platform as a Service (PaaS)

Whether a Private or Public Cloud is built internally, or contracted for, to support SOA, its the "Platform as a Service (PaaS)" layer will be required to have certain functions essential for the support of SOA-based Composite Applications/Services.

The PaaS Layer is "the second" layer of the US National Institute of Standards and Technology's (NIST) Cloud Computing Architecture.  It is the middle layer of the architecture, between the Software as a Service (SaaS) and Infrastructure as a Service (IaaS).  In fact, the PaaS is the first complete actual layer (as opposed to virtual) of the Cloud Computing Architecture.  The only actual functions supported by the SaaS are the user interface functions, which will include the security interface(s) (see my post SOA, the User Interface Service Components, Apps, and Validation before Registering).

The PaaS contains all of the functions needed to run the applications (Services), as well as the actual repository containing the code for the application--for Services, the Service Components.  For a SOA-based set of applications, there are two functions that they require in the PaaS.  First, is the Service Component Registry.  The Service Component Registry is a virtual catalog of the location of Service Components.  It enables the orchestration and choreography processes to find the Service Components, which create Composite Applications.

Second, the PaaS must have Orchestration and/or Choreography Engines with associate Rules Engine and Rules Repository.  I have discuss the difference between orchestration and choreography in my post "SOA Orchestration and Choreography Comparison".  These functions (engines) are based in the PaaS.  The rules engine and rules repository enable and supports automated business rules,which, in turn, enables and supports the organization's policies and standards.

Private versus Public SOA Cloud Architecture

As commonly used, a private cloud is a system within one ownership domain; while a public cloud is a system that crosses ownership domains.  In the language of SOA, private cloud is an Enterprise SOA, while a public cloud is an Internet SOA.  As I discussed in the post on orchestration and choreography, Enterprise SOA uses orchestration (mainly) to execute its composite applications, while Internet SOS always uses choreography.  However, I suspect that most Enterprise SOAs will include both orchestration and choreography, as they will use Service Components outside their ownership domain for occasional ad hoc composite applications; for such things as research and risk reduction.

Another key difference between Private and Public SOA Architectures is that an Enterprise (private) SOA will use an application layer communications system called an Enterprise Service Bus (ESB) to enable the Service Components of the Composite Application to communicate.  On the other hand, the Internet (public) SOA will use the Internet to enable the Service Components to communicate.  For the Cloud Architecture this means that the PaaS of the private cloud will include ESB functionality, while the public cloud will use the interconnectivity of the Internet provided by the IaaS for these functions.

ROI Versus VOI

Return On Investment

According to Investopedia (http://www.investopedia.com/terms/r/returnoninvestment.asp#ixzz1bcKSKpx9)::

"A performance measure used to evaluate the efficiency of an investment or to compare the efficiency of a number of different investments. To calculate ROI, the benefit (return) of an investment is divided by the cost of the investment; the result is expressed as a percentage or a ratio.

The Return On Investment formula:

In the above formula "gains from investment", refers to the proceeds obtained from selling the investment of interest."

 ROI is simple and straightforward, but does not enable or support an organization's ability to make investment decisions.  It is a lagging indicator; it tells you what were good and bad decisions in the past, but nothing about deciding on investments to increase the long-term effectiveness or agility of an organization, which are vital in today's "bonkers" business environment (to use Tom Peters' term), and disruptive technology environment.

One famous example demonstrates this point.  When Jeff Bezos founded Amazon.com in 1994, he knew that he needed customers to create what he envisioned as "The Walmart of the Web".  This meant that he had to decide on a mission, which was to create a highly visited website.  He then settled on at least four strategies.  First, concentrate on selling books, don't try to sell all the products initially.  Second, create a website with a superb user experience.  Third, ensure that Amazon has access to all books any of its customers could possibly want.  Fourth provide value to the customer, to the point of selling books below wholesale cost, to generate website traffic.

Value On Investment

None of these strategies are designed to produce an ROI, but especially the fourth.  In fact, the mission of creating a highly visited site does not create ROIObviously, if the vision of creating the "Walmart of the web" is realized, there will be a good deal of ROI.  But the mission to start to realize the vision does not support ROI--but it does create Value On Investment (VOI).  A decision-maker creates Value On Investment when his or her decisions increases the organization's Production Capability (after Dr. Stephen Covey), that is, the ability of an organization to be more effective at achieving its vision and mission.

Jeff executed and persevered in the mission to increase Amazon's growth to these disciplined strategies to increase Amazon's VOI, which is the point of the mission to create a highly visited website, that is, a highly visited site is much more valuable than a site that is visited very little.  In executing this mission, it did not turn a profit until 2000, much to the ire of many of its investors, but it took an increasing share of the customer base that itself has been growing at an increasing rate.  Therefore, Jeff met this mission for Amazon.

The enterprise architecture for Amazon was constantly upgraded, including software, hardware, and physical infrastructure.  The net result is that Amazon is now competing with all other major retailers for customers.

Unfortunately, too many CEOs give into the nanosecond market that expects an increasing ROI every quarter or sooner.  It is like expecting George Washington to beat the British in every battle in the Revolutionary War.  Washington lost far more often than he won, but together with the other founding fathers, he did create an enormous VOI that subsequent generations have transformed into ROI.  Likewise, NASA in the Moon Mission created VOI that Jeff Bozos, Bill Gates, Steve Jobs, and the world have profited from.

If the people of the "Occupy Wall St." movement have a point, its that there is too much focus on Wall St. for ROI and too little on VOI.  Wall St. is using the wrong metric for the wrong duration.  And they are "leading" the rest of us into bankruptcy as a result.

The Chief Process Office of an Agile Organization

The IDEF0 Pattern and the Organization's Value Engine

In my book, Organizational Economics: the Formation of Wealth, I use the IDEF0 pattern to model the organization.  This pattern has three internal components, Control, Process, and Mechanisms (tooling and skills).  The Control, directs the Process, while the Mechanisms enable and support.  Therefore, the "value engine" of any organization is its Processes; value being judged by how well the organization is achieving its Vision, Mission, or Goals and Objectives.  This was first noted by Adam Smith in Chapter 1 of Book 1 of his book, "The Wealth of Nations".  This means that an organization's processes are semiannually important to their success.

So why is it that in most organizations there is a CFO and a CTO but no CPO?

The CFO and Processes
While Adam Smith created a word model of the organization that anticipated the IDEF0 model--including the controls and mechanisms around the process--he and his successor economic theoreticians ignored the model in favor of researching "capital", as if capital creates value.  The reason for this is that all economic organizations (businesses) have as one of their objectives (if not their only goal) to "make money", that is, to increase the value of the organization.

Adam Smith made a second mistake.  After demonstrating that tooling is a process multiplier and that capital is only used for acquisition of tooling, he then tacitly assigned all of the increase in the value of a process from the "division of labour" to capital's Return On Investment (ROI), when only the process multiplier part of the increase is due to the use of capital and when most of the increase is due to better processes.  This tacit assignment of value has fit nicely with management, finance engineering, and "owners" thinking and preferences since that time. 

[Sidebar: To many, this presents a conundrum.  Many times, as Adam Smith points out in Book 1 Chapter 1, one of the team members of the organization invents or innovates a new process, procedure, function, method, or tool that either makes the process more effective or cost efficient.  It's not clear, unless the organization is directly funding the research and development, that the invention or innovation belongs or should belong to the organization; but, in most companies in the US it does.  The reason is that one condition for employment is that the new employee signs over all rights to new inventions and innovations whether or not they are created on the organization's time.  Clearly, this is not entirely fair to the inventor--it should be a partnership between the inventor and the organization, that is, sharing of the value of the invention or innovation.  And both the work of Karl Marx and Ayn Rand are founded on this issue.]

If All of the ROI from process as well as the tooling is assigned through the CFO, then the assumption of others is that CFO is making good decisions, when actually, the value created by process has little to do with finance.

The Role and Responsibilities of the CPO
The role and responsibilities of the CPO is to ensure that the organization's processes, tooling, and policies and standards, enable and support the organization's vision, mission, and strategies.  Since this is the discipline of Enterprise Architecture, the CPO should be a trained Systems Engineer and Enterprise Architect (as described in several previous posts).

To meet these responsibilities, the CPO must continuously review which processes enable and support which strategies, what tooling supports the processes, and what policies and standards support the processes and which conflict.  By measuring these, the CPO can direct the organization's investments to support the organization in the most effective and cost efficient manner. 

Because of this responsibility, the organization's CFO and CTO must report to the CPO.  The CFO is responsible for the financial resources of the organization.  These are directed into process and tooling investment by the CPO.  The tooling enable and supports the processes; so, changing the direction or changing type of tooling, which is the responsibility of the CTO, is also directed by the CPO.

For most organizations, this new organizational structure would optimize their ability to compete, or at least would optimize their VOI and their agility.

Satisficing Behavior

In economic theory, the is an assumption that customers and consumers decide on products that satisfy their demand.  This has simplified customer behavior sufficiently for microeconomics theory to create mathematical models.  For the past 40 or more years, I have had problems with this assumption.  Recently, I started rereading  Keeney and Raiffa's, "Decisions with Multiple Objectives: Preferences and Value Tradeoffs", Wiley, 1976, to find a definition of it, (even though the authors had not defined it as such).  On page 74, "...a continuing interaction between analyzing what is achevable and what is desirable...[where the decision maker]...must constantly weigh...what he would like to get and what he thinks he might be able to get."  Satisficing behavior is this tradeoff between requirements and resources, policies, and standards.

Systems Engineering and System Architecture in an Agile and Short-cycle Transformation Process

I haven't updated the blog in a while; but I've been working.  Here is a copy of a paper that I will present at an INCOSE Meeting in Detroit early in November.



Enjoy
Systems Engineering and System Architecture in an Agile and Short-Cycle Transformation Process -