Complexity and Power 2

#entarch #orgintelligence In an earlier post, I pointed out the architectural trade-off between Complexity and Power. There may be a choice between a simple-but-inefficient solution and a more sophisticated solution, and this choice has important structural implications. The architectural design of a large enterprise involves any number of these choices.

Furthermore, a given organization has a finite capacity for managing sophistication and complexity, and a limited willingness to invest in the management costs and overheads that may be required to extract the full benefit from more powerful systems.

There are two agendas that each appear to address opposite sides of this situation. The first is the simplification agenda, advocated most persuasively by my friend Roger Sessions, which addresses the problem that most organizations and their support systems (including IT) are riddled with unnecessary complexity.

The second is the maturity agenda, which suggests that an organization can extract more benefit from certain systems and practices and technologies by becoming more sophisticated. Maturity models are typically arranged as a series of maturity levels, and should be derived (although I suspect many of them aren't) from a robust theory of organizational change and technology adoption.

There are some subtle and usually ignored issues in the interaction between these two agendas, but I don't want to go into these issues here. Instead, I want to point to a couple of critical questions

• how much complexity and power does a given enterprise need (requisite variety)
• how should this complexity and power be distributed and connected

The first question looks like a simple engineering question, which should be bread-and-butter for requirements engineers. The need for complexity and power is driven by some set of demands, together with an economic argument that links cost to value (possibly but not necessarily expressed in financial terms).

The second question is clearly an architectural question. Two things are intuitively obvious about the design of complex machines: not every component needs the same amount of power and complexity; however, some components need proportionality of power and complexity. (It doesn't make sense to put a massive engine in a tiny car, and a fast car needs more powerful brakes than a slow car.)

Power and complexity are higher-order examples of so-called non-functional requirements. Architects need to be able to reason about the composition and decomposition of non-functional requirements.

• Let P be some property of systems and components - say performance or quickness or reliability or security or throughput or whatever. If the components of a system have properties P(1) ... (Pn), what can we say about the composite property P of the whole system?

• Conversely, if we have a requirement for the whole system to have property P, what can we say about the properties P(1) ... (Pn) of each component?

The enterprise is a sociotechnical system, so I'm not just talking about technical components here. A racing car needs a driver whose reaction speeds are matched to the speed of the car, and a maintenance team capable of rapidly diagnosing and fixing all the minor technical problems that could occur during the race.

Similarly, an enterprise needs a set of management capabilities whose intelligence is matched (proportional) to the power and complexity of the operations and operational systems - thus we have an architectural view of the enterprise as an intelligent sociotechnical system, with an appropriate balance of power and complexity.

I don't want to hear that the complexity has been completely removed from the technical systems, because I then fear that the necessary complexity has been merely displaced onto the people inside the organization - or worse, onto the customers.

Conversely, I don't want to hear that the complexity has been completely embedded inside the technical systems, because I then don't trust the people inside the organization to fully manage this complexity.

What I want to hear is that there is just enough complexity and power in the technical systems AND at least enough intelligence in the human systems to manage this complexity and power properly. And I expect the enterprise architect to be responsible for maintaining this proper balance.

So-Called Non-Functional Requirements

I agree completely with Nick Malik when he objects to Non-Functional Requirements: the "All-Other" classification.

It is certainly a conceptual error, as Nick explains, to define an engineering concept in negative terms, in other words in terms of what it isn't. But in addition to being a conceptual error, it is also a psychological error, because it makes us believe that the concept is somehow unimportant. Here's what I said in my 2001 book on the Component-Based Business (page 105).

In some cases, some technical requirements of a component can be explicitly derived from the overall solution requirements. In other cases, they are left implicit or delegated to "technical" personnel. These requirements may include such factors as availability, reliability and performance.

These requirements are often regarded as second-class ones, deserving less respect and attention. Much time and energy is typically devoted to getting them right, but this is often grudging and carries less status and reward. Businessmen often call these "hygiene factors", as if to say that they're about the same level as cleaning the office toilets. And software engineers convey a similar attitude when they refer to requirements as "non-functional" - they might as well call them dysfunctional and be done with it.

When I wrote that book, I objected to the term "non-functional requirements" because I believed that such requirements were as important as so-called "functional requirements", but I have since changed my mind. What I now believe is that such requirements are very much more important, at least from an architectural perspective, than the so-called "functional requirements".

This is because it is generally easier to plug in or mash in extra functionality, with fewer architectural implications, than to plug in extra performance. Plugging in a bit of extra functionality is like adding a satellite navigation device or an entertainment console to your automobile. But if you want to carry double the passengers at twice the speed, you have to totally reengineer the vehicle and the engine. Let me quote myself again, this time from last year [Blueprints]

In a traditional waterfall development, many people thought it was a good idea to address the functional requirements first (logical design), and then tweak the design (physical design) until you satisfied the non-functional requirements as well. But when you are composing solutions from prebuilt enterprise services, this approach just doesn't wash. Indeed, it may now be the other way around: if a service assembly fails some functional requirement, you may be able to plug/mash in some additional service to fill the gap; but if it fails the non-functional requirements you may have to throw the whole thing away and start again.

In my opinion, therefore, the architect needs to worry about those requirements that have major structural implications, and can mostly leave the functional requirements to the business analysts and developers.

In general, these structural requirements can't be defined or managed at the level of the individual service, but need attention to the overall geometry of the solution. So a better name for them might be "holistic".

Meanwhile, another extremely important class of requirements arises from the commercial constraints. Someone once told me that when an IKEA designer is given a design task, the starting point for the design is the intended retail price of the finished item. "Design a lamp we can sell for 20 Euros". An SOA equivalent would be to tell the service designer "build me an invoicing service that will operate for less than x dollars per thousand". This aspect of requirements engineering is completely ignored in most design methods, which assume that the price is tacked on at the end.

So I guess anyone who thinks the quality requirements are non-functional probably thinks the commercial requirements are non-non-functional.

---

Update

Words matter. But if we toss "requirements" in favor of *design*, we defenestrate "NFR" in the same motion!https://t.co/ndQeo3YS4e

— VisArch (@ruthmalan) October 20, 2016

---

References

Ruth Malan, Non-Functional Words - Tricky Beasties (January 2014)
Nick Malik, Non-Functional Requirements (October 2008)

Blueprints 2

Reposting my comment to Nick Malik's post on Blueprints, following my previous post on Blueprints. Nick asked me to spell out the implications of my previous comment - whether I meant that we don't need accuracy, or that we should start measuring - and challenged the strong association I implied between accuracy and measurement.

Firstly, let me affirm that I think measurement (in the broadest sense) is a good idea.

I am not sure I know what accuracy means except in terms of measurement. How can we reason about things like "structural integrity" and "quality" without some form of measurement? In engineering, we don't generally expect perfect integrity or perfect quality (which is usually either physically impossible or economically non-viable); we look for arguments of the form "X produces greater integrity/quality than Y" - where X/Y is some choice of material or technique or pattern or whatever. So there are implicit metrics running through all branches of engineering. Software engineering just isn't very good (and should be much better) at managing these metrics and making them explicit. As a result, we don't always see software engineers delivering the maximum integrity and quality for the minimum cost and effort.

So when I'm talking about measurement, I'm certainly not only interested in cost estimation and other project management stuff. I think architects should be thinking about things like the amount of complexity, the degree of coupling, the scale of integration, and you certainly can't read these quantities straight from a UML diagram.

Of course a building blueprint doesn't tell you everything you need either. If you are designing an airport, the blueprint will show how much flooring you need, but will not show whether there is enough space for the passengers to queue for passport control. If you are designing a tower block, you have to have some way of working out how many lifts to put in. In software engineering this kind of stuff is dismissed as non-functional requirements.

All engineering involves estimation. "is this bridge going to fall down" is an estimate.

In a traditional waterfall development, many people thought it was a good idea to address the functional requirements first (logical design), and then tweak the design (physical design) until you satisfied the non-functional requirements as well. But when you are composing solutions from prebuilt enterprise services, this approach just doesn't wash. Indeed, it may now be the other way around: if a service assembly fails some functional requirement, you may be able to plug/mash in some additional service to fill the gap; but if it fails the non-functional requirements you may have to throw the whole thing away and start again.

Finally, I don't say only big projects need accuracy. If a government builds a tiny service to be used by the entire population, a small project might have a massive impact. A garden shed may not need a professional architect: that's not because a garden shed doesn't need accuracy, but because an amateur builder can work out the quantities accurately enough herself.

Reliability and Availability

One of the pleasures of being an industry analyst is that you get to read a lot of vendor material.

Yesterday I came across the following statement in a white paper by Jonathan Purdy of Tangosol on Data Grids and SOA.

"As Business Services are integrated into increasingly complex work-flows, the added dependencies decrease availability. If a Business Process depends on a number of services, the availability of the process is actually the product of the weaknesses of all the composed services. For example, if a Business Process depends on six services, each of which achieves 99% uptime, then the Business Process itself will have a maximum of 94% uptime, corresponding to more than 500 hours of unplanned downtime each year."

This might be true under certain circumstances, but it depends on how the business process is designed, and the degree of coupling within the process. A typical design objective is to compose services in a way that doesn't multiply the dependencies in this way. One of the principles of distributed systems has always been to avoid single points of failure, and this principle is surely inherited by SOA. When used intelligently, loose coupling and asynchrony should make a business more robust.

It is sometimes possible to orchestrate services in a way that that the reliability of the whole is greater than the reliability of the parts. Firstly, there may be underlying services that are not required for every transaction, so the reliability of these underlying services only partially impacts the reliability of the process. Secondly, there may be services that provide multiple or alternative provision of a given capability - alternative process paths can be defined to make the process more fault-tolerant.

That's not going to make the problem of reliability and availability go away of course, and there are undoubtedly some useful things that vendors such as Tangosol can offer in the physical implementation of SOA. And Purdy is right to warn his readers of the risks associated with complexity.

But what this raises for me is the general difficulty of reasoning about non-functional requirements. Do you add them, do you multiply them, do you average them, or do you need to perform a more complicated bit of algebra?


Technorati Tags: availability reliability SOA service-oriented Tangosol

Lightweight Enterprise

One of the interesting divisions of opinion at the SPARK workshop (and surfacing afterwards in the blogs of some of the participants) was about something we might call the weight of the enterprise.

Dare Obasanjo asserts My Website is Bigger Than Your Enterprise. And Jeff Schneider retorts My Enterprise Makes Your Silly Product Look Like A Grain of Sand. So who is right?

The basic issue here seems to be the relative amounts of complex engineering required to produce enterprise-grade software versus web-grade software. Dare (and some other participants at the SPARK workshop, including the guys from mySpace) are producing web software with staggering user volumes - much greater than most enterprises have to deal with.

Dare is scornful of enterprise architects, who (he says) "tend to seek complex solutions to relatively simple problems". He and David Heinemeier Hansson are particularly rude about James McGovern.

But as Jeff points out, "most people who have never seen a large enterprise architecture have no concept of what it is". CIOs and enterprise architects generally regard enterprise software (their own realm) as much more challenging than web software, involving much higher levels of complexity, and much stricter "non-functional" requirements (security, robustness, and so on). Are they right, or is this just narrow self-interest?

Size, complexity, weight - these are basic architectural concepts. Part of the difficulty with this debate is that we simply don't have an agreed language for discussing architecture properly. In my opinon, IT education is very deficient in this area. (See Footnote 1.)

Enterprise Mashup

One way of thinking about enterprise mashups is that they provide a way of achieving enterprise-grade systems without enterprise-heavy engineering. Let me give an example of something I regard as a business mashup. My example doesn't involve Ruby, it doesn't involve web services, and many people might say it doesn't even count as SOA. But it has always been my favourite example of the "plug-and-play" business that I describe in my book on the Component-Based Business.

Tesco Personal Finance (TPF) is an example of what I would now regard as a business mashup. It combines (mashes together) banking services (provided by the Royal Bank of Scotland) with retail services (provided by Tesco).

From Tesco's perspective, this mashup provides an extremely lightweight way of entering the banking business. In the old days, if you wanted to open a bank, you had to collect a large amount of gold, which you had to deposit with the banking regulators to satisfy them of your financial stability. Then you had to open a number of branches, and employ a small army of clerks and managers. This represented a considerable investment and risk - which meant that the existing banks could earn high profits behind high entry barriers.

In contrast, TPF represented for Tesco a low-cost, low-risk way of entering the banking industry. Simply plug in some external banking services (which already satisfy all the necessary banking regulations), and a humble retailer can become a bank overnight.

SOA

Although the Tesco Personal Finance initiative predated the SOA and Web 2.0 technologies we have today, we can now interpret it as a precursor or harbinger of these technologies - almost a non-technical proof-of-concept. (See Footnote 2.)

SOA enables the lightweight enterprise. It does this not through services but through architecture. (That, in my view, was the primary justification of SPARK.)

The challenge of architecture is to deconflict the enterprise software space - to create a genuine separation of concerns. This is easier said than done, and it requires some complex architectural thinking. One of the products of this thinking may be platforms on which developers may use small-scale and simple development techniques to produce large-scale and complex solutions.

See my recent posts on the Business Stack (SPARK Workshop 2) and Enterprise Mashups and Situated Software.

---

Footnote 1 - I have always been critical of university IT courses that teach students to write small programs, and fail to teach them the differences between small stand-alone programs and large interconnected suites of programs. If you go to architecture school, you may never build anything larger than a garden shed with your own hands. But you will have looked at skyscrapers and understood the relevant design and construction principles. You won't qualify as an architect without understanding the scale differences between garden sheds and skyscrapers. But in IT there is no such educational requirement. Vast numbers of people get university degrees in IT-related subjects, and even fancy job titles including the word "architect", without having a clue about effects of scale on software.

Footnote 2 - Sometimes technology seems to make new things possible. But we often find that these things were possible all along, they were just too difficult or expensive or risky. In the 1950s, Stockhausen was producing music that predated the modern synthesizer - and it took him months to produce music that later composers would produce with a few quick knob-twiddles. Some might argue that Stockhausen's achievement was all the greater because of his lack of tools. Similarly, many Renaissance painters might have been able to produce their pictures more efficiently if they had had digital cameras. But perhaps their paintings (and their artistic innovations) were all the greater for being done without modern technology. See my post on Art and the Enterprise.

---

Efficiency and Robustness - On Tight Coupling

People (including Ian Welsh and Chandler Howell) have been worrying about the ability of a tightly coupled world to withstand shocks - including Hurricane Katrina and SARS. Here are some key quotes from their blogs.

• Our society, as a whole, has no surge protection - no ability to take shocks. We have no excess beds, no excess equipment, no excess ability to produce vaccines or medicines, nothing. Everybody has worshipped at the altar of efficiency for so long that they don't understand that if you don't have extra capacity you have no ability to deal with unexpected events. (IW)
• As we have now seen with Hurricane Katrina, even if the capacity were there, the United States’ ability to manage and allocate that capacity is essentially non-existent. (CH)
  

Welsh quotes some analysis from Sherry Cooper and Donald Coxe, comparing a possible SARS outbreak with the flu pandemic.

• Because our society and economy is so much more integrated and so much more connected (for example the flu had to spread by ship back then), and so much more "just on time" that it isn't really a model you can use. We'll likely get hit harder, faster and because many locations have such limited inventories, relying on getting it as they need it, the supply disruptions are likely to be much worse.

Telecoms analyst Martin Geddes offers a potentially more upbeat perspective, at least in relation to Hurricane Katrina, asking us to distinguish between an emergency and a disaster.

• In an emergency, a distributed piece of information calls for a central response. A disaster, the converse. Those best informed are in the field; those best equipped, in the field. The best disaster response system is the one in your hand when the disaster strikes.

But Geddes's optimism is tempered by his distrust of central committees, and his fear they will abuse their power.

• But the changes needed to make things better are politically painful and resistent by incumbent powers. ... I suspect that central committees will determine we need more central response systems, and weaken the economy by taxing everyone hard to pay for it. The exact opposite of the medicine a “network edge” response would dictate.

There are some interesting (and sometimes shocking) details from the Hurricane Katrina experience, and several different levels of incapacity can be detected. From a systems-of-systems perspective, what I find particularly interesting are the interoperability failures.

• Inability of FEMA to work with medical professionals unless they are part of the National Disaster Medical Team. Inability of FEMA to orchestrate external / autonomous agents. (Overlawyered Blog, via Ernie the Attorney)
• Inability of FEMA to provide appropriate support for people with special needs. Inability of FEMA to collaborate with agencies with specialist knowledge and resources. (Conmergence Blog)

My colleagues and I are currently talking to some large organizations about some of the strategic aspects of interoperability, with particular reference to SOA, and I hope to be permitted to publish some of this material one day. In the meantime, I am keen to collect and analyse more public domain examples of interoperability failures. Please contact me, or link to this blog posting.

---

The FEMA response to Hurricane Katrina

Related blogposts:

Efficiency and Robustness - On Central Planning (September 2005)

Efficiency and Robustness - Processing New Orleans mail after Katrina (November 2005)
Technological Progress (October 2005)

Goal-Oriented Requirements Engineering and its relevance to SOA

The i* approach

Last week I attended a seminar organized by the BCS RESG. Modelling your System Goals: The i* approach. The main speaker was Eric Yu (University of Toronto), the original developer of i*. The remaining speakers reported their experiences using and extending i* in a range of projects.

The i* approach is a methodology for goal-oriented requirements engineering (GORE). Professor Yu characterized the distinct nature of Goal-Oriented RE as follows.

Conventional RE	Goal Oriented RE
Describes how things work (AS-IS) and how they should work (TO-BE).	Describes why things work (or should work) that way.
Models of behaviour.	Models of intention and rationale.

i* is particularly focused on so-called "early stage" requirements engineering - before you know what "the system" is going to be. It involves two key models: strategic dependency models and strategic rationale models.

The strategic dependency model identifies goal dependencies between actors. For example, a CarOwner actor depends on "CarBeRepaired", and this can be fulfilled by the BodyShop actor. Put crudely, a goal dependency consists of a pair: {"I want", "I can"}.

i* distinguishes between two different kinds of goal dependencies: hard goals and soft goals. Although this distinction was explained in terms of precision, this seems unsatisfactory to me, since surely precision is itself a matter of degree and timing and negotiation. However, the soft goals that were used as examples seemed to me to possess some other interesting features, which may be relevant to making this distinction clearer. Firstly, the soft goals were generally not amenable to precise specification by the consumer of the goal. Secondly, there is a sense that what counts as satisfaction of the goal is context-dependent and shifts over time. Thirdly, the perceived outcome would generally affect the relationship of trust between the consumer and the provider, and thus the future behaviour of the consumer towards the provider.

This led me to an alternative way of formulating the distinction - according to who owns the goal. In some cases, the consumer determines and decomposes the problem, and then delegates the solution. I think this produces a hard goal that is (or should be) relatively easy to specify. In other cases, the consumer delegates the problem (formulation of) as well as the solution (provision of). I think this would produce what i* calls a soft goal.

So for a soft goal such as FairSettlement, what counts as fairness is delegated either to the service provider, or to a trusted third party such as a regulator. (In some cases, notions of fairness are implicitly delegated to virtual third parties, such as TheCommunity or PublicOpinion, but these are notoriously unstable and unreliable mechanisms.) The significance of this distinction for goal modelling is that identifying something as a soft goal introduces an additional set of concerns for the requirements analyst.

The strategic rationale model identifies causal connections between goals and subgoals for a given actor. Note that the behaviour of an actor may depend on perceived causal connections and associations, rather than actual ones. So if we are going to model rationale properly, we need to include some representation of the actor's beliefs. However, last week's i* presentation did not introduce any notation for belief.

SOA interpretation

Much of the material presented was pre-SOA in outlook, and there were some limiting assumptions about the nature of the systems being built. However, I was looking to push i* beyond these assumptions. What I wanted to explore was the possibility of using i* to design services and service-oriented solutions.

There appears to be a very straightforward mapping from goal dependencies on the strategic dependency model to business services. And these requirements are supported by an understanding of the rationale of each actor. The reason for this is that we want to design business services in terms of added value, and this seems to rely on our having some notion of value from the perspective of the service consumer. SOA is geared towards flexibility, and an appreciation of the possible rationale of each actor also helps build solutions that support a good range of different scenarios.

Another SOA-related motive for modelling dependency and rationale is to analyse compliance (including so-called non-functional requirements). For example, we may identify some system vulnerability, and then identify a reciprocal dependency that provides some enforcement mechanism. We can then look at the system dynamics within a collaboration, to determine the adequacy of this mechanism, as well as any possible side-effects.

In general terms, I am convinced that some modelling of intentions and outcomes is an important aspect of modelling for SOA. In the Boxer-Cohen Triple-Articulation approach to Asymmetric Design, this is known as the Deontic Articulation. i* is much simpler, and widely practised - but is it powerful enough?

Complexities, difficulties and future opportunities

Modelling intentions. There are difficulties involved in modelling the intentions of both organizations and machines, and these difficulties cause some people to say that it doesn't make sense to attribute intentions to either organizations or machines - only to people. I don't agree, for three reasons. The first is that many of these difficulties also apply when we are trying to understand the intentions of people, since people often have confused or concealed intentions. The second is that there are established techniques for tackling these difficulties, which help us to understand the intentions of all kinds of system, at different levels. The third is that we simply cannot make sense of business strategy and organization at a reasonable level of abstraction without somehow talking about organization goals.

Goal mismatch. In practice, there is unlikely to be a neat and exact match between "I want" and "I can". There may be both pragmatic mismatch (crudely: what the provider does is not exactly what the consumer wants) and semantic mismatch (crudely: what the consumer understands is not what the provider understands). This is a form of impedance or asymmetry.

For example, a car driver's real goal may be to have a reliable car with low total maintenance cost. But no service provider offers exactly this service. So the car driver has to compose something that approximates to his real goal, using a combination of car maintenance services and car warranty (insurance) services. (There may be significant commercial opportunities for a value-adding service or service platform in this kind of space. Hence the relevance of goal modelling to business strategy.)

Within i*, the strategic dependency assumes an exact match between the consumer's view of the goal and the provider's view of the goal. To the extent that there is some unfulfilled remnant, this is analysed within the strategic rationale of that actor. But it is not clear to me how this approach would support architectural reasoning about the unfulfilled remnants and the strategic opportunities for developing new added-value services.

Deconfliction. Given that a complex situation contains considerable goal conflict, we need a systematic way of resolving goal conflict. Deconfliction means organizing operations in a way that minimizes the potential risk of interference and internal conflict. Conversely, we need ways of resolving goal synergy.

Note that from a security perspective, goal synergy between (supposedly) independent actors may not be a good thing - especially where it indicates opportunities for collusion and fraud.

Variation. A robust service economy typically needs to accommodate considerable variation in the goals and rationale of the actors. So instead of modelling a single standard strategic rationale, we need to understand the nature of the variation between different rationales, and the implications of this for producing robust and agile systems.

For example, a healthcare system makes some assumptions about the rationale of a patient. But a patient that happens to be a professional athlete (with particular concerns about stamina and performance) will have a very different strategic rationale in relation to healthcare, as compared to a patient that happens to be a healthcare professional (with above average exposure to infection and other risk).

Dynamic and recursive rationale modelling. The causal relationships between goals and subgoals are subject to dynamic effects. For example, many processes operate in terms of surrogate goals - outcomes that are valued not for their own sake but because they are correlated with some real goal. The surrogate goals are available for measurement before the real goals, and may therefore provide useful predictive metrics. (See discussion of Surrogate EndPoints in relation to SOA Pharma.) This means that cause-effect modelling may need to include system dynamics such as delay and oscillation.

There is also a problem that the rationale of one actor may depend on that actor's beliefs about the rationale of another actor. For example, Professor Yu presented an example from insurance, where reorganizing the strategic dependency model could align the insurance broker with the interests of the customer (instead of the broker being aligned with the interests of the insurance provider). In this situation, what the insurance customer demands from the insurance broker depends crucially on the customer's belief as to whose side the broker is on. But that in turn may depend on the insurance broker's beliefs about the customer's acting in "good faith", and about the future commercial tactics of the insurance company. So the whole thing becomes recursive, rather like the Knots identified by R.D. Laing.

Summary

I think the overall approach of i* is extremely interesting for service-oriented architecture, and is broadly consistent with the general approach to business modelling for SOA we have been developing.

---

A version of this post was published in the RESG Newsletter Requirements Quarterly (June 2005).

Contract First

A number of people are championing Contract-First Development within SOA.

For example, Aaron Skonnard of Pluralsight. In a number of recent blog postings on the topic, he reports a sympathetic hearing from Microsoft personnel (Bill Gibson, Simon Guest) and asserts support from Microsoft products (BizTalk Server). [August 27, 2004] [November 11, 2004] [November 11, 2004 (again)] [November 30, 2004]

But I am concerned that some people are basing Contract-First Development on a narrow notion of Service Contract - for example, equivalent to the signature of a service, expressed in WSDL. Sometimes people talk about Schema-First Development, which indicates a concern for semantics as well as syntax. But I don't think this goes far enough.

I previously expressed my preference for the term Design-by-Contract, since this term is strongly associated with a broader notion of Contract including preconditions and postconditions. Even traditional Design-by-Contract doesn't include some of the non-functional obligations expressed in a service contract, such as Service Level Agreements, Security Policy and Commercial Terms, which are essential for distributed computing and SOA. We have used the term Distributed Design-by-Contract to emphasise a broader concern for all these dimensions of a service contract.

Actually, I don't really mind which term we use, provided that we can assume the broadest meaning for the term Service Contract.