Service-Oriented CashFlow

In difficult economic times, the most important business measure for many firms is not profit or revenue growth or cost-saving but cashflow. Which means that the business case for SOA shifts away from relatively boring arguments about cost-saving (economics of scale), and strategic but highly imprecise arguments about flexibility (economics of scope), towards careful comparison of the dynamic economic viability of different business models (economics of governance alignment).

There aren't yet many SOA case studies that talk about cashflow. When I search for "service-oriented" and "cashflow", I keep finding references to a healthcare distribution company Owens & Minor, based in Mechanicsville VA, which started an 4-year SOA project sometime in 2005. (Speed Wins at Owens & Minor, Feb 2005) So nearly finished yet, chaps?

As I've explained in previous posts, the Pay-As-You-Go model has two advantages for the service consumer - better cashflow (because there is less financial latency between expenditure and return) and reduced risk (because you only spend as much as you need). As economic conditions become more volatile, and credit becomes more expensive, both of these advantages become more valuable.

Valuable for the consumer that is. The SaaS vendors (cheerleader Phil Wainewright) quite rightly see this as an opportunity for SaaS. But of course the challenge for the SaaS vendors is how to provide these benefits without themselves incurring excess cost and risk.

Billing and credit control are obviously key elements of the SaaS infrastructure, and some of Phil's clients offer useful services in this space. So are we moving towards a stratified SaaS world: (service-as-a-service)-as-a-service? And what are the economics of that?

---

Phil Wainewright on CashFlow: A Few Financial Home Truths. For mechanisms for handling billing see Phil Wainewright on Easing the SaaS-to-cash cycle and Marco Seiriö (RuleCore) on More CEP SaaS Pain.

Note: for various reasons, we now prefer the term Economics of Alignment. 

Updated 25 October 2013

Mark to Market

Politics and Economics

There have been a number of calls by politicians around the world for an end to the financial practice of "mark-to-market".

Defenders of the practice try to explain that "mark-to-market" simply means taking latency out of the accounts of individual companies, and improves overall transparency. ["Mark-to-market" accounting fight goes down to the wire]

Opponents of the practice point to its effect in amplifying the recent catastrophic falls in share values, particularly banks. European politicians (including David Cameron and Nicolas Sarkozy) have suggested the practice should be suspended or modified [Sarkozy seeks change to fair value rules, Nicolas Sarkozy's mission impossible?] and the US Senate has now given the SEC powers to suspend mark-to-market.

Financial regulations based on the mark-to-market principle were introduced after Enron. [Enron-era accounting reforms blamed in financial crisis] Some politicians (including Mark Sanford) have pointed out a troubling pattern of yesterday's solutions causing today's problems. [A Bailout for All Our Bad Decisions?]

Implications for SOA

Some SOA champions in the financial sector have seen the elimination of latency as one of the critical benefits of SOA. These benefits might now seem contingent and short-term rather than fundamental and lasting. Solving one set of problems, but contributing to new problems.

There is now a real possibility that regulators may impose new and more complicated valuation rules for complex financial assets. If SOA has been correctly implemented, then plugging new valuation rules into existing applications will be a fairly quick and painless procedure. However, if it turns out that the service-oriented architecture needs radical restructuring to accommodate such changes, then this might indicate that the SOA applications weren't correctly architected in the first place.

SOA was supposed to make business more capable of withstanding change. So are banks with a decent service-oriented architecture now in a (slightly) better position to weather the catastrophe? Perhaps we shall soon find out.

---

Biographical Notes

• David Cameron is the leader of the UK Conservative Party.
• Nicolas Sarkozy is the President of France, and former leader of the centre-right UMP party.
• Mark Sanford is the Republican Governor of South Carolina.

Real-Time Events

Opher reports a car accident (unplanned events again) and concludes that people need to process events in real-time and not in batch.

Congratulations to Opher on his fast reactions, and commiserations on the slower reactions of the driver behind. Clearly there are some events you have to process in real time. But I hope he is not implying that all events must be processed in real-time. When the fuel tank indicator appears, do you refuel immediately or do you wait until you reach the next gas station? How often do you have the vehicle serviced?

I think the critical question for systems designers here is to determine which are the events that call for a real-time response, and which are the events where a batch response is more appropriate.

There are also events that call for a low-latency (extremely fast) response, but don't count as real-time. For example, in the financial markets, there may be short-lived arbitration opportunities, which means you can make a lot of money if you can react within a small number of milliseconds. This is not a real-time requirement, because nobody expects you to pick up every single opportunity - just catch a reasonable number of them. (The reactions of the frog should allow it to catch just enough insects to fill its belly - but some insects escape to breed more insects. The insects get faster, and so do the reactions of the frogs.)

Surely the event infrastructure should be capable of handling any of these patterns.

Service-oriented security 2

Form Follows Function.

In a recent post, Bruce Schneier makes some interesting points about the relationship between Architecture and Security [via Confused of Calcutta].

"Security concerns have always influenced architecture."

"The problem is that architecture tends toward permanence, while security threats change much faster. Something that seemed a good idea when a building was designed might make little sense a century -- or even a decade -- later. But by then it's hard to undo those architectural decisions."

"It's dangerously shortsighted to make architectural decisions based on the threat of the moment without regard to the long-term consequences of those decisions."

End-to-End Process.

In a separate post on Voting Technology and Security, Bruce Schneier describes the steps in ensuring that the result of an election properly represents the intentions of the voters.

"Even in normal operations, each step can introduce errors. Voting accuracy, therefore, is a matter of 1) minimizing the number of steps, and 2) increasing the reliability of each step."

Whether this is strictly true depends on the architecture of the process - whether it is a simple linear process with no redundancy or latency, or whether there is deliberate redundancy built in to provide security of the whole over and above the security of each step. Bruce himself advocates a paper audit trail, which can be used retrospectively if required to verify the accuracy of the electronic voting machines.

Shearing Layers.

Security management doesn't necessarily operate on the same timescale as other elements of architecture. Our appproach to service-oriented security - indeed, to SOA generally - is based on the notion of a layered architecture, in which each layer has a different rate of change. (This is based on the Shearing Layers principle (now known as the Pace Layering principle). Thus the security layer is decoupled from the core business layer, and also from the user experience layer.

Previous Posts: Adaption and Adaptability, Business IT Alignment 2, Service-Oriented Security

SOA Security

Service-orientation affects security in (at least) four key ways.

Increased automation and decreased latency. By making computer to computer automation the de facto method of business transaction, there is great potential for finding and exploiting loopholes before they are closed. When processes are automated, business processes can fail for unforeseen reasons that automation actually exacerbates. Web services take the level of automation much further, and consequently the potential risk.

Self-service business design. With web services, consumers and providers need to be treated asymmetrically, the provider needs to identify users - the consumer needs to identify providers and each party to the exchange needs to operate on highly defensive principles. And as web services consumers and providers are implemented as automated exchanges between computers the principles of defensive components is highly relevant. A technical viewpoint might be that providing consumers are authorized, the service may be provided.

In this litigious age, we also need to be acutely aware of corporate liability. Does a consumer have the authority to enter into a specific transaction? Are there complementary business transactions in place that take authentication beyond simple identification?

Dynamic policy-driven operation. Run time behavioral change driven by business rules allows dynamic change and potentially much more flexibility of business process. Collaborations with third party web services introduce elements that are not completely under the control of the primary transacting organization.

Federated security. The essence of an SOA is composition and orchestration of multiple services, which requires security context to be shared between collaborating services, rather than independently organized.

Technorati Tags: SOA service-oriented security

SOA and database

A traditional view of data is as a structured collection of attributes. Each attribute provides information: in Bateson's phrase, it is a difference that makes a difference. For example, let's suppose the attribute CUSTOMER CREDIT LIMIT controls the outcome of some business transaction - whether the customer is permitted to place an order, or has to pay upfront. (The difference in the attribute value causes a difference in the transaction outcome.) We are accustomed to having such attribute values stored in a massive database somewhere, and passed around in XML packets. But the attribute value is itself the result of some calculation, judgement or negotiation. In a genuinely real-time enterprise, this calculation, judgement or negotiation would be done in real-time, with zero latency. Of course, there are organizational as well as technical reasons why we don't generally do this.

So the things in the database are simply those items that it happens to be more convenient to store than (re)discover. At any point in the future, some items may shift from storage to real-time discovery. The content of the data layer should not be fixed for all time, but we should expect it to change as the costs of real-time discovery (both in performance and in design/development effort) are reduced.

Thus SOA erodes the traditional database data layer. This is NOT just removing data replication (as Lawrence Wilkes advocated in December 2000), but removing data storage altogether. At the present technological state-of-the-art (SOTA), this is only going to happen in isolated areas.

In his ServerSide article The Fallacy of the Data Layer, Rocky Lhotka imagines the wholesale deconstruction of the data layer, and the impact on the application, although he doesn't go as far as I am suggesting. Then when he is attacked in the subsequent discussion for his apparent SOA enthusiasm, he sidesteps and says he was being sarcastic. But while there may be considerable scepticism about the current viability of his remarks, it seems perfectly reasonable to present this as a hypothetical future scenario, if and when certain technological and organizational conditions are met.