Thursday, September 23, 2010

...aaS the alphabet

AaaS - Architecture as a service
BaaS - Business as a Service
CaaS - Corruption as a Service
DaaS - Data as a Service
EaaS - Enterprise as a Service
FaaS - Father as a Service
GaaS - Government as a Service
Haas - Avocado
IaaS - Infrastructure as a service
JaaS - Java as a Service
KaaS - Karma as a Service
LaaS - Logging as a Service
MaaS - Mother as a Service
NaaS - Network as a Service
OaaS - Outsourcing as a Service
PaaS - Platform as a service
QaaS - Quality as a Service
RaaS - Recovery as a Service
SaaS - Software as a Service
TaaS - Testing as a Service
UaaS -  Undertaking as a Service
VaaS - Verification as a Service
WaaS - Water as a Service
XaaS - Xenophobia as a a Service
Yaas - Yet another as ervice
ZaaS - Zero as a Service

Sunday, September 19, 2010

Dangerous conversations with Nigel Green

Every couple of weeks, Nigel and I talk about "stuff". This week it was more on his Agile Business Change Design (ABCD) style (details here).

There's still a bit that is causing us both to scratch our heads - and that is how to transition from actor based behaviors to role based thinking. Value networks do a fantastic job of showing what happens by role, but current state organizations are not necessarily organized that way.

In the current state we often see the same role being performed by different people/organizations, or an organization taing on many roles or usually a combination of both. That's likely to be inefficient, but efficiency isn't really the goal.

The beauty of the ABCD style is that it is lightweight, simple, effective, narrative based (as opposed to technique and methodology based). However there are some points at which technique rears its ugly head. That can potentially be a slippery slope - leading to large, methodology bounded, consultant driven, expensive approaches. A favorite technique, applied by MBAs especially,  is "cluster analysis". grouping "things" by common properties in order to look for some thread on which to hang a thesis. However, just because it can be long winded and overblown doesn't mean it has to be. The property that we need to cluster around here is the property of "like". When I am checking someone in, I may have to change a reservation, so I am acting "like" a reservation agent.
The ABCD Change Agent (ugh, I hate that term) should  quickly in the synthesis step be able to discern the essential roles from the "Commander's Imperative". The actual organizational structures (silos or "cyclinders of excellence") will come out of the operational reality narratives. The skill comes in allowing those in the operational reality to see the roles in a non-threatening way. To recognize that the process isn't an attempt to sabotage their work and working lives, but to more clearly delineate what the organization plans to have done.
Help desks/support centers are often quite confusing in this kind of analysis because the agent at the desk is by definition some kind of generalist. The agent will often have to behave in a variety of different roles - and overlap with people applying the same role in other parts of the organization.
Help desk staff are extremely valuable to have in these sessions because of their breadth - and because of what they see at the Demand end of the operation - they are in touch with what is actually happening, as opposed to what "management" thinks should be happening.
So for the ABCD CA, a goal is to make sure that people on the demand side of the organization - where the money is made, where the contacts with the market the company serves are established and reinforced are fully and properly represented. After all we want to hear how it is, not how some manager's or director's fantasy of how it should be.

Monday, September 6, 2010

Transactions and eventual consistency

My friend, colleague and fellow arechitect Nigel Green (Twitter @taotwit) and I were on a call this morning. Putting the world right of course, but as a by-product of that, we got to discuss systems of record and systems of reference. That led us into some further discussion about Operational data Stores (special cases of Systems of Reference) and eventual consistency. The emerging pattern is an important (and not the only one possible) one.

So first some clarity around terms. I am using System of Record here to mean the authority system that can always provide the absolutely, legally correct value of an item. It is the "ultimate truth" for the item. Every other copy belongs to a System of Reference.

So in my favourite home banking example, my bank's view of the transactions is the system of record, my view (in my local Quicken Copy) is a system of reference. Checks don't bounce because of what happens in Quicken, they bounce because there isn't enough money in the account maintained by the bank.

The is a special kind of system of reference, one that can affect transactions in the system of record. Especially important where the transactions executed in the system of record are relatively long running. Take for example an airline reservation. In the example, I am going to simplify the business rules, simplify the way things actually work just to keep this post short. There is clearly more, but I just want to expose a pattern. The system of reference that I will be describing here is a system of reference that can act on the system of record, e.g. by causing a booking leg to be canceled. An example here might be that if you don't check in for a specific leg, the rest of the legs in the booking may be canceled.

It might (and I use might advisedly) be sensible to make a system of reference responsible for that determination, and the application of the rules, rather than trying to do the rule processing in a system highly optimised for transaction processing. Detecting negative events ("the dog didn't bark") is often quite time consuming and compute expensive.

So a pattern might be for the system of record to deliver a stream of transactions through the event network to  one of these systems of reference. This system of reference can make decisions/determinations about "things" which it will potentially want to either report on, or sometimes cause changes to the system of record. There are a couple of ways it could cause the system of record to be updated.

It could treat its own world as a kind of write-through cache. In other words, updates could be made to the system of reference (and any persistent stores that it maintains) and that updating method could issue "change transactions" to the system of record. But what happens if the system of record refuses the transaction for some reason? Now we have to back out the change in the system of reference. Sounds like a case for 2phase commit, whoopee. No we can really gum up the works.

Another approach might be to make the change ONLY in the system of record and wait for that change to come through to the system of reference. That's a kind of eventual consistency model. The system of reference is eventually consistent with the system of record. This is very satisfactory if the time intervals are short. So if the system of reference were within a second or 2 of the system of record, this eventual consistency model might be very handy. If it were over several minutes/days/weeks, this might be very unsatisfactory indeed.

So in my Quicken example, I would be inclined to update the Quicken ledger as I created the transactions. e.g. wrote the checks), and issue the transactions separately (mailing the checks) realizing that I may have to compensate later if some expected event did not occur in the meantime.

In my airline example, I would be very inclined to issue the update only to the system of record, let it apply the rules and then change notify an event after it had done its magic. I would need t make sure the pipe is high speed so the changes can be notified quickly enough, and we would still have to have some compensation mechanisms in the system of reference for when "weirdness happens". However, by forcing the updates through the system of record first and having the system of record eventually consistent gives us a very high performance system with quite a simple set of mechanisms.

Now thinking this way, I can start to see RESTful capabilities on my system of reference. I genuinely am manipulating resources in a very straightforward way. It is all about GET/POST - GET from the system of record, POST to the system of record for use of the data. Internally the system of reference synchs with the system of reference through the event delivery network.

A neat bundle of thinking for one kind of problem.