X hits on this document

21 views

0 shares

0 downloads

0 comments

9 / 11

revenue) from this single process. All of it could start with entries by wait staff into the menu order entry system. As checks are paid, (confirming those orders), sales would be entered, and totaled at the end of each shift. Store managers would receive a report on both shift revenue totals and also on inventory updates (so that they can make any adjustments to the automatic reordering process, both those items regularly ordered and those ordered as replacements based on usage).

Individual store revenue data and inventory replacement or increment needs will be rolled up daily on both a regional and a company-wide basis. A revenue dashboard will allow HQ’S executives to see daily results on a real time basis, drilling down into regional, brand, and individual store results.

But for this ambitious plan to happen there must be a process for facilitation, coordination, policy management, and control. SOA Governance will offer the restaurants those management and control functions. It will insure all of the restaurant locations use a consistent process for entering orders and collecting and processing checks. It will offer local, regional, and HQ management insight into both daily revenues and the management of food and supply inventories. As individual restaurants, groups, or the entire organization plan for new SOA projects they will be able to easily discover and reuse the intellectual property (IP) they created for this application. For a project of this size, additional controls and infrastructure can be justified, so the initial plans might include not only some rudimentary SOA Governance for coordination and oversight, but also more advanced building blocks like an ESB, permitting the easy connection of applications and services.

The future of SOA Governance: An Assessment

It’s easy to predict the near future of SOA Governance: we’re going to have a lot more of it as SOA becomes the way most large enterprises (and many medium-sized ones) do their application development and life cycle management.. It’s easy to predict what will happen in the very long run (say, 20 years or more). We’ll probably have found a new and still better way of doing things – perhaps based on the power of nanocomputers or neural networks. It’s the in- between part that’s tricky. But good planning requires that we try for that five-to-ten year view, so here are some educated guesses bases on lots of experience and the facts at hand.

From Nascent to Mature SOA Systems

Today, most of the SOA systems we’re looking at are very young. Most of them – with a few exceptions – are a few projects, general below mission critical level. Many of them consist largely of service-enabled legacy investments with a few newly created services added. We talked to companies who had written ten services – or 20 or 30 – for two or three projects. That was actually a lot. Many companies were still more in the talking about or planning for stages.

That’s fine, as long as you don’t miss the paradigm parade. While we’d agree that only a few pioneering spirits want to be the very first to try a new technology, those who invest earlier get more for their money, because they can use the technology longer, while still being in the period of that technology’s full bloom. Those who wait too late are just getting started when something more interesting comes along (which, inevitably, it does) and whatever you just did becomes a lot less interesting.

Of course, some technologies barely have a blossoming summer and a fall harvest at all – they just fade away with the little buds still tightly closed. It might be lack of interest or insufficient differentiation, but it’s more likely that something more interesting just pushed it aside. Other technologies just stay around forever, in spite of analysts predictions that they will be fading any

Page 9

October 18, 2006

Document info
Document views21
Page views21
Page last viewedMon Dec 05 18:59:16 UTC 2016
Pages11
Paragraphs140
Words5093

Comments