jump to navigation

SOA is all things to all marketers; but business as usual to CIOs and BAs December 15, 2006

Posted by Cyril Brookes in General.
1 comment so far

We’re in an era when IT and BI are defined by marketing slogans. As with so much of the IT techno-sphere this is both a benefit and a demerit. In the “old days” the marketing hype was basically directed at infrastructure, hardware and operating systems; System 360 for example. We CIO types could focus on the application strategy, more or less uninhibited by energetic sales people and consultants grabbing the ear of the CEO and pointing out the error of our ways.

Not today. SOA in particular creates a marketing furor. The noise is so great that there is hardly an IT related article, aside from academia of course, that doesn’t contain some reference to it. CIOs have to have a SOA strategy, whether they believe or not, or they’re dead.

KM was a failure for marketing hype, no one could understand what it meant!

At risk of falling into the same melting pot, I believe there are a number of inconsistencies and probable errors in all this cacophony.

The words Service Oriented Architecture mean little on their own, I mean it’s Motherhood-and-Flag stuff. What useful architecture isn’t service oriented, depending on your definition of service?

As for SOA 2; please! We’re not that sure about base SOA.

How can apparently otherwise sensible, normal, reasonable human beings devote so many column inches to this concept? For example:

SOA is an architecture built around a collection of services on a network that communicate with each other. The services are loosely coupled, have well-defined, platform-independent interfaces, and are reusable

A more business oriented description is:

SOA services are designed to interoperate with different development technologies, which make them flexible and reusable, and by creating an abstraction layer between business logic and business process layers; SOA enables businesses to focus on business processes rather than low-level application and integration issues.

You may recall, Dear Reader, Object Oriented Design was the 80s fad, one source defined its benefits as:

OOD can yield the following benefits: maintainability through simplified mapping to the problem domain, which provides for less analysis effort, less complexity in system design, and easier verification by the user; reusability of the design artifacts, which saves time and costs; and productivity gains through direct mapping to features of Object-Oriented Programming Languages.

Key terms in these, and many other, descriptions appear to be: maintainability, i.e. flexibility (?), mapping to the problem domain (i.e. the business process), reusability.

There’s not much new under the sun, or in the IT shop, just re-emphasis of the old success criteria. Business process reengineering isn’t dead in the consultant and analyst marketing department, its just called BPM, SOA, or whatever and carries on.

I don’t have any quarrel with maximal use of web style interconnection, and the consistency that can bring to inter-application (or service if you will) communications. In the 80s that didn’t exist as an option, now it does, so let’s use it. And the data warehouse is obviously a marvelous concept for enabling loose coupling between applications, services, external and internal business processes. So let’s use it, but don’t look for an acronym.

But that’s it, in my view, the rest is, or ought to be: common sense, good practice and high quality requirements specifications. Simple, game over.

I do have an issue with all the focus on BPM and its role as a part of an IT systems architecture that’s deified by the analyst/consultant pressure group. This is supposed to enable reusability at a higher level than simple reusable code segments or inter-process communication.

High level reusability of applications is, and was with OOD, largely a myth in my experience. An interesting exposition on this topic is given by Joe McKendrick in Another vote against the value of ‘reuse’.

Business processes change with time and only small differences can render reuse of applications impractical. On the other hand, data models are mostly constant (if well done, that is), unless the business changes radically. That’s why the data warehouse has such a (relatively) permanent process decoupling potential.

I guess that, in the end, the CIOs have plenty of defenses against the dark art of SOA vendor pressure. The definitions are now so vague, all encompassing, and inconsistent, that they will always have work completed and projected that can be seen as conforming to something.

As long as they are combining good requirements definition and implementation practice with web interfaces and data warehousing (and who isn’t), they are as much SOA compliant as needs be.

Ed Yourdon is one of the originators of Structured Design, the predecessor of OOD and all methodologies. His latest book Death March is described as a revelation in that he appears to debunk much of what he espoused many years earlier. I believe may yet see a revolution against this hi-brow, consultant speak stuff that’s got to have an acronym to describe it; lest perhaps the emperor is explicitly seen, i.e. without clothes.

.One final observation on SOA and its popularity in the white paper, marketing blurbs. There’s a rush to associate products and consulting services with SOA. A common way of doing this is to use the comic, equally inappropriate, phrase: joined at the hip.

SOA must have a large number of hip joints; including, at least:

Perhaps we could add serendipity, nirvana, holy grail, silver bullet, or just B/S?


Knowledge is Power – But Only Sometimes in BI December 1, 2006

Posted by Cyril Brookes in General, Tacit (soft) information for BI.
1 comment so far

The management, or exchange, of soft (tacit) information (knowledge) is a current focal point in the BI space and we hear the ubiquitous quote frequently.  Unfortunately, knowledge isn’t always power, in fact it’s rather like Francis Bacon’s original Latin version:  Nam et ipsa scientia potestas est (my favored translation is: For knowledge, too, is itself a power).  

The indefinite article makes all the difference.   

Two interesting papers on the Knowledge is BI Power theme I’ve read lately are: Do we need internal knowledge markets?  by Jean Graef of the Montague Institute and  Making a market in knowledge is Lowell Bryan’s (McKinsey & Co) contribution.  Graef summarizes the Bryan article as follows: 

According to  Bryan, most companies have tried one of three approaches to managing knowledge with “mixed success.” (1) Technology alone doesn’t work because most corporate documents are out of date, poorly written, and can’t be easily “parsed” (read) by computer software. (2) Content “pushed” to employees by a centralized staff of communicators doesn’t work because “it’s not very valuable to most frontline employees.” (3) Allowing each business unit the freedom to manage its own knowledge works “because it facilitates exchange among small groups of workers with common interests,” but it “provides just a fraction of the potential benefits of exchanging knowledge on a company-wide scale.” 

Bryan’s solution is an internal knowledge market, which he defines as “the exchange of items of value among parties who don’t know each other.” 

Key qualifiers of knowledge’s potency in the BI context include, in my experience: 

  • Not all knowledge has value 
  • Knowledge’s value is ephemeral 
  • Most valuable soft knowledge is tacit 
  • Knowledge must be explicit to be useful in BI 
  • Knowledge is often spread over several minds 
  • Just-in-time collaboration is needed to create required knowledge 
  • If knowledge is not categorized it cannot be shared 
  • Categorization must be according to a vocabulary (taxonomy) of standard terms 
  • Context impacts both value and implications of knowledge 

Importantly, people who want to know something don’t know if it exists, and those who know it don’t know if it is useful, or to whom.  Even if the knowledge does exist in some useable explicit form, it often requires some facilitator to bring its relevance to the people who need it.  Some form of context dependent information push is therefore desirable. 

The central thrust of my argument is that many commentators appear to assume that the knowledge to be shared, managed, marketed, exchanged or whatever, actually exists in tangible form.  In my experience, the most valuable knowledge is most often created through collaboration between two or more minds at the time it is required to be utilized.   

Authors can be encouraged and motivated to make explicit their tacit knowledge;  if they know they know it.   Editors can review and collate knowledge that is already explicit. 

 It is my view that the real issue to be resolved in the business enterprise is the stimulation of knowledge creation as and when it’s required, say in response to a new problem or the resurfacing of an old problem.   

I don’t believe that a market approach is sufficient, but definitely incentives are required.  These ought include corporate recognition awards that counteract the natural cultural barriers that limit collaborative inclination among staff. 

A second theme of mine is the need to recognize that there are three types of BI related knowledge available, or being created, in a business enterprise (Independent; Qualification and Reference).  They have different power attributes, and require different treatment in the sharing context.  I’ve discussed these in some detail in an earlier post. 

To summarize my opinion on how to maximize knowledge collaboration: 

  • Stimulation via news and industry related feeds is a critical starting point for commentary that leads to knowledge creation 
  • Subject experts who add value are key elements of the collaboration scene; they separate the value from the dross 
  • Escalation of the more important discussion threads, to a wider readership, is necessary since not all items have same value to the enterprise 
  • The reward mechanism is critical, as discussed 
  • Work-shopping of intelligence ought be facilitated to overcome the natural reluctance of people to share information they are not sure about with those they do not know. 
  • Categorization of knowledge items is essential, and should be done according to a vocabulary of standard terms. 
  • Knowledge is certainly one power in BI , but not always.