Blueprints

Nick Malik has prompted a great discussion on the difference between accuracy in architecture and IT. He asks why IT architects don't produce blueprints that are as accurate as those produced by architects in the traditional world of physical construction.

The kind of accuracy Nick describes in traditional architecture is about quantity. The costs of a building are largely determined by the physical dimensions. (The cost of the carpet depends on the floor area.) So the first person who looks at the blueprint is not the builder but the quantity surveyor. The blueprint has to be good enough to enable reasonably accurate cost estimation.

We don't usually do that in IT. There is no How-Many/How-Much column in the Zachman framework. You can't work out quantities from a UML diagram. In a pre-SOA world, we thought cost estimation was largely about counting the number of components to be constructed (simple, medium, complex) and putting them into a time/effort formula. But this approach to cost-estimation is increasingly irrelevant to SOA.

If you are only building a garden shed then you possibly don't need a professional architect or surveyor. If you are building a tower block then you certainly do. The people who are doing serious architecture in an SOA world are those operating at internet scale - for example redesigning Skype so that it doesn't fall over on Patch Tuesday (see Skype Skuppered).

Squidoo Lens: Service Engineering

Just Tidying Up?

In a recent post on my other blog, Gordon Brown, Enterprise Architect, I pointed out the resemblence between an enterprise architecture and a written constitution, and suggested that the new UK prime minister might be open to both of these initiatives.

However, the current UK foreign secretary may not be with him on this one. Mrs Beckett has spoken out against formal constitutional reform for the EU, and appears to believe that nothing more is required than tidying up the rule book. [BBC News, June 17th, 2007]

There are of course semantic issues here, as my friend Robin Wilton pointed out in his blog: Semantics Invictus. There is a political incentive to avoid anything that counts as constitutional change because this would have governance implications (specifically, a referendum would be required).

How does this apply to Service-Oriented Architecture? Clearly there are some people within the IT world who would take the Margaret Beckett line. They believe they don't need a full enterprise architecture, together with all the governance that implies - there are just a few systems that need a bit of tidying-up.

For example, the CEO of a company called Health Watch Technologies avers that "the first step toward many innovations is simply tidying up systems" [Special Report on Medicaid 2006]. And a recent FT article describes Huge Benefits from Tidying Up.

But the examples quoted in the FT article go way beyond just tidying up, and include the work that is going on at BT to develop a service-oriented architecture, with some impressive results already.

There may be some resistance to formal enterprise architecture in some organizations, but there is no arguing with the benefits of doing things properly.

Enterprise Architecture

What exactly do enterprise architects do?

What they generally do is plan, design and govern systems and other artefacts, based on abstract models of the business. They may be responsible for things that support the enterprise, they may be responsible for things whose scope extends across the enterprise, but they are not responsible for the enterprise itself.

What they don't generally do is architect the enterprise. The key decisions that affect the geometry of the enterprise are generally taken at board level, and involve major decisions about mergers, acquisitions and spin-offs, product platform and strategy. Does Fred Goodwin (boss of Royal Bank of Scotland) consult an enterprise architect to work out the potential synergies and structural implications of acquiring ABN Amro? I think not.

In other words, most enterprise architects practise business-oriented architecture, but not architecture-oriented business.

Given that enterprise architects don't actually architect the enterprise, and given that their function is closer to city planning and governance than true architecture, Nick Malik suggests that they should be called something else. [Nick Malik: Go Build an Enterprise Architecture. Neil Ward-Dutton sympathizes with the suggestion, but thinks it may be Swimming against the tide.]

Why not call them planners?

Service Planning 2

Nick Malik asks Should SOA be Top Down or Bottom Up. He suggests that architects need to pay attention to the big pieces and can ignore the small pieces.

"While the architects do not need to know about every moving part, they DO need to be aware of the largest of those parts, and make sure that they are managed well. This is similar to city planning, where the city needs to work with a large employer or a large retailer (like Walmart) to make sure that roads and parking and congestion issues are managed, without having to worry about cafe and card shop that are also employers, but have a minimal impact on the infrastructure."

Some people argue for a "fractal" notion of the service economy. While the word "fractal" isn't always used in its precise mathematical sense, its use seems to imply that the service portfolio should have a good mixture of different sizes / granularities (although not necessarily in the same architectural layer). Such a mix of different sizes is also advocated by Christopher Alexander.

In city planning, small retail outlets such as cafes and card shops may individually have less economic or environmental impact than a major retailer such as Wal-Mart. But collectively, they may have at least as much impact. (This is a "long tail" argument.) One of the challenges for city planning is to achieve a good balance between the large few and the many small. (Of course this raises questions of governance as well as architecture, politics as well as economics.)

If the total weight of the large pieces is greater than the total weight of the small pieces (whatever measure we choose for "weight"), then this is itself an architectural choice, with important implications for project agility and enterprise agility.

Most people in this game think they know what the terms "top-down" and "bottom-up" mean, but these terms are commonly used in different (contrary, confusing) ways. If an architect only worries about fitting the big pieces together, and assumes that the small pieces will somehow look after themselves in the remaining ("negative") space, this sounds like one version of what some people would call "top-down".

What if the architect concentrates on providing "positive space" in which the small pieces can thrive, and prevents the big pieces from encroaching on this space. What if the architect concentrates on the interfaces between the pieces, rather than the pieces themselves. Is this "top-down" or "bottom-up"?

I don't really care what we call this - although it would be good to have a more precise way of talking about it - but I think this is an equally valid strategy.

Technorati Tags: SOA service-oriented architecture governance longtail

Enterprise Architecture versus SOA?

In a provocative post yesterday, David Linthicum suggested that Enterprise Architects should be fired if they don't appreciate SOA. Not surprisingly, this is resulting in a hostile response from people (Uche Ogbuji, Mark Nottingham) who are saying that it's not Enterprise Architecture that's the problem, it's SOA. Or rather the SOA vendors. Mark (who used to work for BEA) blames the Big Vendors.

I have some major concerns with the way SOA (or some watered-down version of SOA) is being implemented in large organizations, sometimes with the encouragement of vendors. But I don't think all the blame for this can be placed on the vendors. (Hey, they're vendors, what do you expect from them?)

I also have some major concerns with the way Enterprise Architecture is being implemented in some large organizations - talking endlessly about Business-IT Alignment but reduced to playing meaningless games of Framework Bingo.

In my consulting work, I'm increasingly finding that effective SOA and effective Enterprise Architecture go hand-in-hand - you probably can't do a decent roadmap or business case for one without considering the other.

I think David Linthicum raises some good points in his post, but I don't agree with his conclusion that you should fire enterprise architects who don't appreciate SOA. It is probably true that some enterprise architects don't deserve that job title - but it's not because they don't appreciate SOA but because they actually aren't very good enterprise architects in the first place.

I have generally found that good enterprise architects are eager to address the issues that matter to their organizations. This certainly doesn't entail (why should it?) an uncritical acceptance of SOA. In my earlier post on Optimism (in reply to Jeff Schneider) I said that "it is not the role of the architect to be optimistic". But it does entail striving for a flexible and joined-up and cost-effective architecture. Frankly I can't see the point of an enterprise architecture if it doesn't do any of the things on David's checklist.

Technorati Tags: EA Enterprise Architecture SOA service-oriented

For Whom

There are several enterprise architecture approaches (TOGAF, DoDAF, MoDAF) based on the work of John Zachman and his Kiplingesque sextet:

"I keep six honest serving-men
(They taught me all I knew);
Their names are What and Why and When
And How and Where and Who."

One of the extensions we’ve been looking at for SOA is the possibility of introducing a "For Whom" column. This reflects the fact that value is not just experienced by “The Enterprise” - regarded as a single centralized pot of costs and benefits - but may be distributed across a federation or ecosystem.

For example, does a service intermediary add value for the service provider, or for the service consumer, or both? Does a change in business policy improve the whole supply chain, or have we merely pushed the problems upstream? Does a security layer mitigate risk for the bank or for its customers? Does a compliance monitoring service protect the interests of the directors or the shareholders?

Some people have told me that this is already implicit in the "Who" column. Or perhaps it is implicit in the "Why column. But I don't believe that many enterprise architects currently interpret the "Who" or "Why" columns in this way.

"For Whom" is important for SOA when we start to look at service networks that span several organizations. One organization may produce a business case for doing some SOA, but this may only be viable if other organizations cooperate. Participation in a network is based on some form of self-interest (each participating organization gets out more than it puts in) and/or some form of governance (the organizations collaborate according to some agreed or imposed regime).

In addition, "For Whom" is important for security engineering. Some organizations focus their security on protecting their own internal systems against a narrow range of direct threats, but seem to pay little attention to a broader range of indirect threats against themselves and their customers. In my view, an organization such as a bank should take a 360-degree view of security, and should try to provide real security for its customers and their assets, as well as for itself.

Update

Philip Boxer has published a more radical critique of the Zachman framework on the Asymmetric Design blog.

Notes

The distinction between "For Whom" and "Who" is similar to the distinction between "Customer" and "Actor" in Soft Systems Methodology (SSM). Some readers may be familiar with the SSM acronym CATWOE, which stands for Customer, Actor, Transformation Process, WorldView, Owner, Environment.

del.icio.us links: CATWOE Zachman
Technorati Tags: Enterprise Architecture SOA Zachman

The General and The Particular

In his post What do you need to know to be an IT Architect? Simon Guest (editor of the Microsoft Architecture Journal) identifies some key elements of architectural knowledge: IT Environment, Business / Technology Strategy, Design Skills, Quality Attribute Skills, and Human Dynamics.

I think there are two important clarifications we can make here.

Firstly, Simon's starting point is, rightly, know-how (skills) rather than body-of-knowledge (theory). Nick Malik makes a similar point in his post on Enterprise Architecture Interview Questions: "proven abilities and past experiences, and not book learning".

The distinguishing characteristic of an architect, in my view, is a certain way of paying attention to a certain class of problems and opportunities. (Just as a chess grandmaster has a vast body of knowledge of past games and variations, as well as a complex mental library of patterns, but these are only useful for playing the game of chess.)

Therefore the architect's knowledge (of the organization, of the business) needs to be active knowledge, what Vickers called appreciation.

Secondly, when Simon talks about "the organization", "the business", and so on, these terms can be interpreted in two ways. Does the architect need to know about organizations-in-general, business-in-general? Or does the architect need to know about this particular organization, this particular business?

In his blog last year, Ali Arsanjani characterized this choice as one between two philosophers: So is Kant right or Hume? and Back to Kant and Hume. (See also my comments to his posts.)

Do architects concentrate on some apriori (generalized, enterprise-wide or industry-wide) schema (Kant), or do they remain grounded in the specific local requirements (Hume)?

(Some people refer to this choice as top-down/bottom-up. But I think this terminology is vulnerable to wide misunderstanding, because different people have different orientations - is the business at the top, or is the generic model at the top?)

I believe the best architects are those that can do both - who have both general knowledge/know-how and particular knowledge/know-how, and can make intelligent connections between the general and the particular. In what ways is this bank like any other bank, and what particular things differentiate this bank from other banks?

That's how we train our SOA architects to think.

Technorati Tags: SOA service-oriented

Business-Oriented Architecture

Hal Pierson writes: "if I had to guess what a service oriented architecture will eventually look like, I would guess that it would reflect the business architecture".

Here is the blurb for my 2001 book on the Component-Based Business.

New businesses can apparently be wired together from existing pieces at astonishing speed. A large grocery chain plugs in some extra "components" and becomes a bank, almost overnight. What are the rules of this game, and are there any pitfalls? And what are the implications for IT? There is currently an explosion of new businesses - not just small start-ups but substantial launches. Many well-known brand names are cut-and-pasted onto new products and services. And not just e-versions of existing businesses either, although that's certainly part of the story. A grocery store opens a bank or insurance company. An insurance company opens a hospital or car breakdown service. Suddenly, and without warning, there's a major new player in the marketplace. Is this new? No, of course not. But what is new is the way it's done, and the speed. Thanks to the plug-and-play approach, a new business can be rapidly assembled as a loosely coupled set of partnerships and services, with a complex business process spanning many organizations. These business structures (and the software and services that support them) evolve in complex ways, beyond the control of any single player. Even a substantial company can now be viewed as a component of a much larger system, rather than as a self-contained business operation, and this has huge implications for planning and managing at all levels. In this book, we explore these new business opportunities in terms of components, relationships between components, and the assembled systems. We demonstrate techniques for planning and managing evolutionary change, and we identify strategies for business survival and success.

The issues addressed in my book are now becoming mainstream as the technological agenda of service-oriented architecture (SOA) starts to converge with the strategic agenda of the service-based business (SBB). This implies an approach to business strategy that involves dynamically managing the geometry of the business. (To achieve a fully adaptive enterprise we typically need to implement a variable geometry.) We can find elements of this thinking in some of the methodologies coming out of IBM and Microsoft, although from what I've seen so far I don't think any of these methodologies go far enough.

Hal calls this Business Oriented Architecture. If anything, I'd prefer to call it Architecture-Oriented Business. As Hal indicates, this calls for architectural thinking at the business level, which need to be aligned with architectural thinking at the information/software level.

Technorati Tags: adaptive enterprise architecture SOA service-oriented

SOA and Enterprise Architecture

The old-style IT practitioner always regarded distribution as a source of complexity, and instinctively preferred non-distributed solutions wherever possible. The Service-Oriented Architecture turns this attitude on its head. The whole point is to distribute functionality across a network of services.

The well-known Zachman framework for Enterprise Architecture has a column for Network, but historically this has generally been regarded as referring to geographical location. Zachman himself calls this column “Where” – the other columns being Data (“What”), Function (“How”), People (“Who”), Time (“When”) and Motivation (“Why”).

But in a fully service-oriented economy, we must abstract away from geographical location. Web Services and related technologies allow the geographical location (and other physical locators) to be completely transparent. Instead, we can now interpret “Where” as referring to locations within an abstract topology or network.

In the service-oriented business we regard the enterprise as a (possibly federated) network of services. It is not geographical distance that matters any more, but abstract notions of distance, including commercial and semantic distance.

http://www.cbdiforum.com/secure/interact/2003-12/service_oriented_architecture.php3