Tom Graves

This one starts with a note from Belgian enterprise-architect Kris Meukens:

I couldn’t agree more with your post last month on “Architecture is non-functional“, and appreciated it very much.

However, the case is most often made for “system” architecture. With the right arguments – as also my experience has proven – that case can be made convincing to business people. But as soon as one tries to translate the same case to the less tangible “enterprise” architecture, I have been experiencing a lot more difficulty, although I am convinced it translates well.

I was wondering if you have any thoughts on this and/or you could help me on this one, which I consider pretty fundamental to enterprise architecture.

There are at least two different ways you could use to tackle this, depending on the context and who you’re talking with.

One is to take the same approach as Richard Veryard describes in his blog-post on ‘So-Called Non-Functional Requirements‘. In IT architecture, the functions are often relatively straightforward, and wouldn’t change all that much between different implementations. But some of the ‘non-functional’ requirements can demand huge differences in system-design, and will themselves demand different supporting-functionality: consider a system for a low-security context (store-directory for a shopping-mall) compared to a high-security-context (funds-transfer in ATM in a shopping-mall), or a low-bandwidth informational system versus high-bandwidth transactional system versus medical-imaging system for use in remote conditions with unreliable power-supplies. As Richard says:

The architect needs to worry about those ['non-functional'] requirements that have major structural implications, and can mostly leave the functional requirements to the business analysts and developers.

So the same applies to an organisation: it’s relatively easy to plug in new functionality or features into organisation-level systems (which is why projects so often suffer from ’scope-creep’ or even rampant ‘feature-itis’), but changes to ‘non-functional’ themes such as safety, quality, environmental management and interpersonal communication may well demand a fundamental re-think right the way through the entire organisation. In effect, the ‘non-functional’ determines much if not most of the ‘functional’ – especially when we take it right up to the whole-of-enterprise level and view the overall vision and values of the extended-enterprise as the foundational ‘non-functional requirements’ for the business as a whole.

Hence the second approach to this, which is to draw a distinction between organisation and enterprise.

The crucial distinction is that an organisation is bounded by rules and responsibilities, whereas an enterprise is bounded by shared commitment – in effect, by principles and values.

Each organisation exists within the scope of a broader ‘extended-enterprise’: its suppliers, partners, customers, prospects, overall environment and so on. (For more on that, see ‘What is an enterprise?‘) Without that relationship between organisation and enterprise, the organisation literally has no purpose: or, to put it the other way round, the enterprise is the organisation’s purpose. Which, in terms of what we’re discussing here, means that the foundational ‘non-functional requirements’ for an organisation are defined by its enclosing enterprise.

We then link that back to Richard Veryard’s point, that the ‘non-functional’ requirements create more fundamental demands than the ‘functional’ ones.

To do this, we first need to note that organisations form natural hierarchies, and likewise enterprises also form their own natural hierarchies. (Enterprises actually form intersecting ‘communities of interest’, or ‘communities of commitment’, and occasionally organisations do so too; but for these purposes it’s easier to think of them as simple nested hierarchies.) For example, ‘the business’ is often viewed as a single ‘the organisation’, encompassing a structure of business-units consisting of departments made up of sub-departments which consist of work-teams and so on, each with their own explicit rules and responsibilities. And sometimes the boundaries of an enterprise will coincide with an organisation-boundary: for example, each of those ’sub-organisations’ is also an enterprise in its own right – a ‘community of commitment’.

Hence the somewhat misleading notion that ‘the organisation’ is also ‘the enterprise’. It’s misleading because of that point above: the foundational requirements for an organisation (whole-organisation, business-unit, department, work-team etc – whatever its level in the business-hierarchy) are defined by the enclosing enterprise for the respective organisation – not by the organisation itself. If ‘the enterprise’ has the same boundaries as ‘the organisation’, the foundational requirements in effect become self-referential – literally detached from the outside world. Which is not a good idea…

[Update: the term 'Step' below may be misleading, especially for some non-native English speakers - my apologies. Here it's not a step within a process, for example, but means a pace or step outward from the boundary of the organisation. If in doubt, use 'Layer' as an alternative to 'Step'.]

In practice the foundational requirements need to be drawn from an enterprise at least three steps larger than the organisation in scope:

• Step 1: partners and suppliers, including outsource and contract relationships
• Step 2: clients and prospects, including ex-clients and anti-clients
• Step 3: non-clients and community, including government and broader environment

Again, these are nested – so for an IT department, for example, Step 1 might include HR, equipment providers and outsourced help-desk, Step 2 would be the business-contacts, project-managers and general users of the department’s services, and Step 3 would include overall business policy and governance. In a production environment, Step 1 is the incoming side of the immediate supply-chain, Step 2 is the outgoing side and the schedulers, and Step 3 is production policy. At the whole-organisation level, the steps are as described above: partners and suppliers, clients and prospects, and non-clients and community.

Step 1 largely defines your costs; Step 2 largely defines your income. The relationships between them are relatively simple to model – such as with the Business Model Canvas. Hence many business-planners stop there, because those transactions do make straightforward business sense: but that’s a dangerous mistake, because as you’ll see from each of the examples above, governing policy is primarily derived from the commitments and values of Step 3 – not Steps 1 or 2.

In ISO-9000 terms, policy is derived from ‘vision’ – the guiding commitments, principles and values of the enclosing enterprise. In effect, policy is ‘non-functional requirements’ that determine response to change. And as ISO-9000 explains, it is indeed possible to run an organisation for a while without high-level guiding policy: but as soon as there’s any significant change, you’ll run that organisation straight into the ground – which, again, is not a good idea. So as enterprise architects, we need to understand and model all the way out to Step 3, in order to identify the overall requirements for the ’system’ of any type of ‘organisation’ at any level within the organisational hierarchy.

To summarise in perhaps over-simplified form:

• Step 0 (’the organisation’) is the boundary of the ’system’ in scope
• Step 1 (’partners and suppliers’) describes functional requirements for input-side for that system
• Step 2 (’clients and prospects’) describes functional requirements for output-side for that system
• Step 3 (’non-clients and community’) describes non-functional requirements for overall governance for that system

To paraphrase Richard Veryard again, we can mostly leave the functional requirements in Step 1 and Step 2 to the business analysts and developers; the architect needs to worry most about “those ['non-functional'] requirements that have major structural implications” that arise from Step 3.

So perhaps use this as a way to explain to others the criticality of ‘non-functional’ requirements at “the less tangible ‘enterprise’ level” – in other words, how far out we need to model ‘enterprise’ in order to identify the real requirements for ‘the enterprise’ that is the organisation as a whole.

Hope this is useful, anyway – and as usual, constructive comments / suggestions etc would be gratefully received!

Several people have asked me for more information about the book I’m writing at present, ‘The Business Anarchist‘, so here’s a quick summary of the themes and structure.

Who or what is a ‘business-anarchist‘? Anyone who works with inherent uncertainty in business in an intentional, disciplined way – working with the uncertainty rather than trying to ‘control’ it. Often it’s not so much a person as part of a business-role – a necessary part of that business-role. (Most of the examples in the book will come from my own field of whole-of- enterprise architecture, but the same principles apply in just about every other type of business-role.)

Why ‘anarchist’? Anarchy is about working without rules, working ‘outside the box’. When ‘business as usual’ breaks down, a disciplined form of anarchy is probably the only way through to something new that works well in the new business context.

‘Kiddies-anarchy’ and real anarchy: Anarchy has had a very bad press in the past, mainly because of what I describe as ‘kiddies-anarchy’ – an overdose of presumed ‘rights’ without responsibilities, especially in terms of causing disruption and destruction without any awareness or respect of the consequences for anyone else. Real anarchy is very different – arguably the most difficult of all political forms, because there are no easy rules to fall back on or to blame. Some entire organisations have been run on anarchic lines – the Quakers have done so for centuries – and even some businesses – such as Ricardo Semler’s Semco Group – but here we’re mainly focussing on an often-unnoticed yet everyday set of roles and responsibilities within an ordinary, everyday type of business.

What kind of business? Any business, and any type of business – for-profit, not-for-profit, government or social – from a huge global conglomerate right down to the local bridge-club or the school parent/teacher association.

Business-analyst and business-anarchist: Business-analysts deal with certainty and predictability: they refine the figures, crunch the numbers, track the trends. When your business world is reasonably stable, you need your analysts to help you optimise efficiency and maximise returns. But when your business world is not certain, not predictable, that’s when you’ll need your anarchists. And you’ll need your anarchists then, too. Your analysts can only tell you how to do more of the same, better – which is good, of course, in its own context, but it doesn’t help when what you really need to do is something different.

What’s different about how business-anarchists work? The quickest one-line answer is that analysts rely on rules and algorithms; anarchists rely on guidelines and principles.

What principles should business-anarchists rely on? Obviously this varies from one context to another, but from my work in whole-of-enterprise architecture the three most important design-principles seem to be these:

• There are no rules;
• There are no rights; and
• Money doesn’t matter.

These three principles, and a fourth follow-on principle, Always enhance adaptability, provide the overall structure for the book.

There are no rules: Rules provide a spurious sense of certainty that can let us down badly when our business-world changes around us. The real world is much messier and more complex than any system of rules that we could devise. Hence at times it’s necessary to start off from the assumption and expectation that there are no rules: instead, we have to rewrite the rule-book, by working back to the core-principles from which the rules originally arose. A simple everyday business-example of this is embedded in the ISO-9000 standard on quality-systems:  work-instructions provide ‘the rules’ that we need for real-time practice and process, but when the world changes, we need to rewrite the work-instructions by working upward to procedure, policy and, if necessary, overall vision.

There are no rights: ‘Rights’ are an important social fiction, but as with rules, they don’t actually exist in the real world, and in themselves they tell us almost nothing about how to create the conditions that such ‘rights’ would require. In practice, apparent ‘rights’ arise from mutual, interlocking responsibilities – so it’s those responsibilities, and not the purported ‘rights’, that are where we need to start. This has important implications for business-architecture and enterprise-architecture that will be explored in some depth in the book – for example, we need to ask serious questions about “What do shareholders own?” if they possess all the ‘rights’ for the business but without any real responsibilities.

Money doesn’t matter: Money is important for every business, of course, especially in a commercial context – but as with rules or ‘rights’, it’s not the place where we need to start. Money is also only one small part of the overall economy in which the business operates: reputation, trust, attention and respect all need to exist before any money will be placed on the table. And if we state – or show – that we’re only interested in ‘making money’ from our customers and community, why would anyone want to engage with us? As with other ‘rights’, money is solely a social fiction, and profit is an outcome of being ‘on purpose’ to values: to achieve the profits that we may desire, we first need to start from values, with a values-architecture that describes how we engage with everyone within the extended-enterprise of the business.

Always enhance adaptability: Change is the only certainty: we therefore need to design for that fact. Mistaken notions about rules, rights and money often serve only to slow us down, placing the business at risk as the world changes around us. This sections of the book explores how to embed the ‘business-anarchist’ principles into everyday business-practice, especially in business-architecture and enterprise-architecture.

—

More details to follow over the next few days, including book-cover, cover-blurb, ISBN numbers and so on. Publication-date is fixed as late-April, so I need to keep moving!

Not actually ‘cryptic’ in the usual sense – just that the cafe in the Crypt below the church-cum-concert-hall of St Martins-in-the-Fields is a useful and pleasant place for meetings in the middle of London. (It’s just off Trafalgar Square, and a very long time since it was literally “in the fields”, next to the garden of the convent that is now known as Covent Garden.)

Anyway, two great conversations yesterday with Chris Potts and Sally Bean on enterprise-architecture and an assortment of other related topics. More details after the ‘Read more…’ link.

Read more…

It’s another week. Which means another exciting (or somesuch) collection of Tweets and links. Which – yes, as you’d no doubt expect – means the usual categories preceded by the usual ‘Read more…’ link.

Over to you if you’re interested, anyway.

Read more…

It’s another week of Tweets and links – somewhat late due to overload elsewhere. Usual categories, usual ‘Read more…’ link.

Read more…

Another instalment from the long-running discussion on LinkedIn about values-architecture. This part is about one of the more confusing ‘red-herring’ distractions in values-architecture, namely the notion that discussing anything other than money is somehow supposedly ‘politics’, which is therefore ‘wrong’ – and thence the mistaken belief that we should only discuss monetary metrics in a values-architecture.

The discussion went on for quite a long time, but it’s perhaps useful to record in some detail because it shows quite a variety of angles from which to tackle this specific type of objection.

This’ll be another long one, so I’ll place the usual ‘Read more…’ link here.

Read more…

And it’s back with another collection of Tweets and links, usual categories, usual mixtures, usual ‘Read more…’ link:

Read more…

Just received from Open Group the usual stream of invites to the next TOGAF enterprise-architecture conference, this time in Rome, in late April.

Perhaps it’s just spring or something (which it isn’t here, of course – ‘here’ being cold, damp, grey England), but there’s a real sense of change in the TOGAF air. This time, amazingly, there’s barely a Cloud in the sky: instead, at last, almost all of it is enterprise-architecture. Real enterprise-architecture.

As Enterprise Architecture matures there are many challenges which face the fledgling profession, but perhaps the most troublesome is how to find a way to communicate effectively with the business.

EA is fast becoming a business activity and is leaving behind the safe haven of IT. Language and communication now stand front and center as the current and most critical element of EA but how do we go about overcoming what, for many enterprise architects, is arguably our greatest challenge?

This event provides an ideal opportunity for EA professionals to better understand the overriding need to more closely align the practice of EA with the requirements of business decision-making at ‘board room’ level. It will better prepare all EA professionals to make real and significant contributions to the development of business strategy.

“Communicate with the business”, we might note – not “to the business”, which has been the arrogant attitude of IT for so many years. And being explicit that we need to be “leaving behind the safe haven of IT” is a very important step indeed.

But wait: it gets better:

Evolving EA from IT to Business
Plenary theme (Monday)

We all know that EA is evolving and that gives enterprise architects a problem, because it implies that we have to evolve too.

We also know that we need to get closer to business, to make IT-business alignment a thing of the past. It simply isn’t enough for there to be IT-business alignment, there should only be business with IT being as much a part of the business as finance, sales, marketing or operations.

At this conference we will seek to open up the discussions that we, as enterprise architects need to develop to move forward and embrace the future of EA. Attendees can learn about our key challenges in this field, the different approaches to success and can be guided by those who have overcome the challenge of successfully crossing the divide.

And as a key enabler of this change in focus, EA Professionals need to change the language of EA, from “techie speak” to a much more business-oriented language that relates directly to the organization’s key business functions. The conference will explore a future in which enterprise architects engage in meaningful conversation in the Board Room as a matter of course, and in which the enterprise architecture itself constitutes a key enabler of corporate decision-making.

In other words, that crucial shift from ’strategic planning’ to ‘strategic conversation‘. At last.

But wait: it gets better still, in business-architecture terms at least:

Extending EA to the Enterprise
Plenary theme (Tuesday)

The Business Architecture is a key component of any Enterprise Architecture, proving the direct linkage between other, IT-related components of the EA and the key strategic drivers and imperatives of the business. It is the key enabler by which Enterprise Architecture can truly extend its reach to the heart of the enterprise.

Those working in the field of Business Architecture are uniquely positioned to establish tomorrow’s best practices. In this session thought-leaders and leading practitioners in Business Architecture will present the critical success factors for today’s Business Architect.

TOGAF is an industry consensus framework and method for enterprise architecture that is used by organizations around the world. TOGAF is a live framework, continually evolving to accommodate best practices. At this conference we will show how TOGAF can be used today to present Business Architecture in a meaningful way to the business.

In other words, for the first time, business-architecture is described by Open Group as a distinct discipline in its own right, separate from but interrelated with IT-architecture. That’s a huge shift: in the TOGAF 9 specification, released barely a year ago, business-architecture was still in effect described as a jumbled-up grab-bag of “everything not-IT that might impact on IT”.

The only point I’m wary of here is that, in escaping from IT-centrism, this version of EA still risks falling straight into the next trap, that of business-centrism or organisation-centrism. No doubt business-folks might prefer us to do that, but in the long run it’s actually as dangerous as IT-centrism. It’s true that business-architecture should be centred round the needs of the business itself – but just like IT-architecture, that’s not enterprise-architecture either.

An organisation is bounded by agreed rules, or, in the case of a business, by legal obligations; but an enterprise is bounded by feelings and values – which is not the same at all. Without a grounded awareness of its extended-enterprise – the surrounding ecosystem within which it operates – business-architecture risks becoming self-centred, literally narcissistic, and guaranteed to fail in the longer term. An architecture that has a broader scope than the business itself becomes essential to guide the architecture of the business – and that’s what a true ‘architecture of the enterprise as enterprise’ will provide.

Even so, the description of this upcoming conference is very good news: a real sign that we’re at last getting closer to a true enterprise-architecture. At last. At last.

Another week, another collection of Tweets and links…

A handful of extended conversations, and a special section on the TOGAF conference in Seattle. Beyond that it’s the usual categories that I hope you find useful, preceded by the usual ‘Read more…’ link:

Read more…

Yup. But they don’t like the results of simplistic, which is what we’ve got at the moment.

Note first that transaction-taxes are a _method_ to tackle a _symptom_. If we go straight to impose taxes without exploring the underlying issues, we’re likely to fall into the classic IT-industry trap of pre-packaged ’solutions’ looking for a suitable problem – the cart-before-horse’ syndrome. (For US folks especially, there are also some serious concomitant questions about where that money will go once it passes into government hands. )

This is not trivial: an unexpressed, unreleased value will keep on building until it eventually explodes, destroying not merely the business-model but at lot else whilst it’s at it. A colleague, for example, was once at a creditors’ meeting which very nearly became a lynch-mob: traders, you have been warned!

Since the previous post on ‘Values-architecture 101‘, the discussion on LinkedIn on values-architecture and values in business continues happily unabated. Still seems worthwhile, and also seems useful to re-post some of it here to make it more generally available.

I know I tend to write long, so perhaps unsurprisingly one person commented:

@Tom You asked for suggestions.

Keep it simple. Keep it brief. That is what business people want.

Yes, true. But business-folks also don’t like the results of simplistic, which is mostly what we get at the moment.

Condensing the simple out of the complex is darned hard work, which is perhaps why most people prefer simplistic. Even though it doesn’t work.

The path from complex to simple necessarily goes through something called ‘work-in-progress’ – which invariably and inevitably is going to be somewhat messy, tangled, confusing and the rest. And long-winded, too. Hence, my apologies, ‘cos this is indeed a work-in-progress…

Anyway, for those who don’t mind things that only halfway towards simple, more after the ‘Read more…’ link.

Read more…