About Simple Architectures for Complex Enterprises

I read with great interest Roger Session's new book "Simple Architectures for Complex Enterprises".

The area that is most relevant to me regards the reuse of ABCs (i.e. units of process and technology components, that Roger calls Autonomous Business Components).
Let us assume that there are differences in the business processes in various regions. The way that loans are processed are different for New York, Asia and Frankfurt, leading to three ABCs, each specialized for regional business conditions (legal, administrative, cultural, environmental).

The alternative is to have one Global Loan Processing system

The question is - which avoids complexity better?
If I start with the Global system, and see high complexity due to it having to handle different regions, (i.e., regional variables add high complexity), I am tempted to partition the system into regional systems. The complexity falls from N*N*N to 3N as the systems can be tested and changed independently.

On the other hand, if I start with regional systems, I am tempted to combine the systems in a bid to reduce costs (and complexity) - as mentioned in the book.

I asked Roger to comment on this apparent contradiction.

Roger emailed me back -

I don't know if there is a simple answer to your question. It comes doesn to how similar the three systems are. And it is also important to keep in mind that just because architecturally we are considering systems to be different, that there aren't opportunities to reuse work at the implementation level. And in some cases, we can break out that part that makes them different into other ABCs.

My current rule of thumb is, "When in doubt, make them different". I think in general more harm is done by trying to force things to be the same than allowing them to be different. But this is very dependent on individual circumstances, as the case study in my book shows.

I find this perspective highly pragmatic and useful.

Roger has a blog related to the book as well.

The Toyota Way and Software companies

Arun recently pointed me to a news report that he found particularly amusing. It is about an Indian software company trying to adopt the Toyota way. Unfortunately they seem to be getting it wrong.

Since August 2007, employees of LogicaCMG India have been maintaining hourly logs of their activities at work. This includes the nature of work, the status of the work, tasks completed, meetings attended; indeed, just about everything, including the time spent at the cafeteria.
It then shows how many hours were spent on each production activity including support , testing, development, project management, review and rework ; on preventive activities like process improvements and self-development ; on organization support activities like interviews , training, meetings and customer visits; and finally on idle time like waiting-for-work or personal time.
The report adds up all that to give the productive hours utilized. It then subtracts that from the previously calculated "available hours", and Verma gets the unutilized time. In the one instance we were shown, the unutilized time stood at 1.5 hours out of a total of 656 available staff hours, or 0.23%.
"I can check such things project-wise, location-wise , competency-wise . I can check the changes over time. I can exactly identify who was responsible for a delay in a project. In fact, we have broken things down in a way that everything can be quantified," says Verma.
Verma of LogicaCMG admits there was resistance when employees were asked to log in hourly details: "There were questions like: I'm doing intellectual work, why should I do such things." But over time, everybody appears to have got into the groove.

To me this resembles Taylorism and Scientific Management . I thought they went out of fashion in the 1950s.

Instead, a focus on Lean Operations might be called for -

The Principles of Lean

Improve Continuously - Get your employees to suggest ways to improve and implement the good ideas on a continuous basis.

Involve Everyone - Software programmers dont like to enter detailed logs of how they spent every minute. Especially if that data is being used to find out "who delayed the project".

Eliminate Waste -

There are 7 types of waste ("S W I M T O O") which can be recognised in most organisations:

• Scrap (or Defects) - Do you detect defects early? Do you practice prototyping? Can your employees "stop the production line" if they see problems?
• Waiting - Is your staff kept waiting for signoffs, approvals etc.?
• (Excess) Inventory - Are you understaffed/overstaffed in a particular area - E.g., is your Business Analyst swamped with volumes of paperwork awaiting processing? Are your servers underutilized?
• Motion - Do you have unnecessary movement and travelling?
• Transportation - Are your teams flat enough? Does information make unnecessary hops? Does your staff have to keep switching between unrelated projects?
• Overproduction - What steps in your process don't add real value?
• Overprocessing - Do you require six sign-offs when three will do?

Reusable processes and SOA

Joe McKendrick has an interesting post on SOA rituals that made me smile.

I agree that hatered against the 'poor beleagured' Silo may be misplaced. Some boundaries are necessary for you to be able to act and implement. If everything in the enterprise was to be implemented and controlled globally, very little could get done.

Joe then describes what he thinks SOA really is - "it is a scope of architecture, like Building Design vs. Urban Planning". I disagree. I think the "Urban Planning" space belongs to Enterprise Architecture. With SOA, I don't worry about what lies behind the service interface. When doing EA, I consider all the technologies and applications and systems in the Enterprise. I look at the gaps in the Business Architecture and look for ways to fill the gaps. I do this irrespective of whether they provide loosely coupled re-usable services or not (which is what I see SOA as doing).

On Reusable processes and SOA

James McGovern has a post where he casts a big shadow on the prospect of reusable services. He thinks reusable business rules might actually work but not reusabe services. In his experience, applications get rebuilt or rewritten if they have to be reused.

The way SOA is generally positioned, services should encapsulate reusable business processes. I don't find too many potentially reusable services when I look around.

• They require access to data. Enterprise data is often local, not global. Regulatory requirements might prevent you from having global data stores (especially in the banking domain.) In any case, data for UK is likely stored in UK and data for Malaysia is likely stored in Malaysia.
• The processes differ. The business process in one location may well differ from another location. There are differences in the business environment (cultural, political, administrative, regulatory, legal, geographical, economical etc.) that require that the process be different.
• They involve people and roles. Large enterprises usually have global employee databases. However, the employees are organised differently and have different roles - again due to different business environments.

These factors greatly diminish the set of services that can be simply reused without customization.

Moving on to other topics

A lot of write offs have occurred since my last post

Some lessons that could be learnt from the subprime crisis -

• Ways to generate wealth must be sustainable. It is not sustainable to for an industry to "sell lemons to each other indefinitely" as some have described it.
• By slicing and mincing risk and passing it all around, the overall risk does not go down.
• Models for risk must seriously take liquidity into account. What is a bond worth if no one wants to buy it?
• Risk (i.e. loans) should not be created by parties that have no stake in what happens subsequently.