Looking back on Year 2

As a follow on to my blog post that reflected on year 1 of EA at Bristol (http://enterprisearchitect.blogs.bristol.ac.uk/2012/04/17/looking-back-on-the-first-year-of-my-ea-role-at-bristol/), here’s a summary of the top three key things I covered in year 2: Raising the profile of EA: a two-hour workshop with the Portfolio Executive (http://www.bris.ac.uk/planning/programmesandprojects/portfolioexecutive/). This senior decision-making group within the University were interested to […]

Looking back on Year 2

As a follow on to my blog post that reflected on year 1 of EA at Bristol (http://enterprisearchitect.blogs.ilrt.org/2012/04/17/looking-back-on-the-first-year-of-my-ea-role-at-bristol/), here’s a summary of the top three key things I covered in year 2: Raising the profile of EA: a two-hour workshop with the Portfolio Executive (http://www.bris.ac.uk/planning/programmesandprojects/portfolioexecutive/). This senior decision-making group within the University were interested to […]

How to build a Roadmap – Sequence

This post explores the step where we discover the optimum sequence of actions recognizing predecessor – successor relationships. This is undertaken now that we have the initiatives and the prioritization is done. What things do we have to get accomplished first, before others? Are there dependencies we have identified that need to be satisfied before moving forward? What about the capacity for the organization to absorb change?

Schism and doubt

On Friday 14th June, there was a public meeting of the EAST group, entitled Perspectives on Enterprise Architecture and Systems Thinking, kindly hosted by BT in its offices near St Paul’s. Tom Graves has posted a detailed write-up on his blog At ‘EA and Systems-Thinking’ conference.

What is the purpose of dialogue between EA and ST? Putting aside the debate about what the labels “Enterprise Architecture” and “Systems Thinking” might mean, there is certainly a thought that the two (or more) communities can learn from each other. There are strengths and weaknesses on both sides – so we may be able to produce a critique of EA from an ST perspective, or a critique of ST from an EA perspective. For example, in his presentation, John Holland asserted that “EA is broken – How ST can help”. (See Tom’s blog for summary.)

This kind of material often arouses a certain kind of resistance. “He’s not talking about me, he must be talking about someone else.” Where are the EAs to whom such a criticism as John’s might apply? Surely the fact that we are going to these meetings, or reading these blogs, or participating in these Linked-In discussions, puts us into the most sophisticated and reflective quartile? 

One of the fundamental questions underlying discussion of EA and ST is imagining some kind of landscape with more or less distinct zones: EA over here, ST over there, this or that school of EA, this or that school of ST, good EA versus bad EA, authentic ST versus fake ST, mainstream versus next practice.

I have written several pieces on the relationship between Enterprise Architecture (EA) and Systems Thinking (ST), on this blog and elsewhere, but such pieces are always open to challenge by those who disagree about the correct use of the labels.

  • “That’s not what real Enterprise Architects do.”
  • “That’s not really Systems Thinking.”

So it sometimes seems that we cannot even start talking about EA and ST, and about the relationship (if any) between them, until we can agree what these terms mean. The desire to name things properly is an ancient one, and can be found in the Analects of Confucius. (See my post on the Wisdom of Confucius). But the prevailing desire to impose one’s own definitions leads to endless and mostly unproductive debate on Linked-In and elsewhere. For this meeting, we hoped for a more productive energy, and I like to think we largely succeeded.

Some of the speakers fell into a dialectic mode of presentation – on the one hand EA, on the other hand ST. This can be useful as a starting point, but if the distinction between EA and ST is taken too seriously it may drive a wedge between practitioners. As Tom commented, “there don’t seem to be any clear distinctions, any absolute boundaries that determine who’s ‘in’ and who’s ‘out’ – all a bit blurry all round, really.” For my part, instead of trying to avoid making any distinctions whatsoever, I put up a few slides with some provocative and playful distinctions, flagged with “possibly” and “tongue-in-cheek”. But I haven’t always been consistent about this, and (as someone pointed out to me) I probably need to be more careful when making a rhetorical contrast between “mainstream” and “next practice”.

The EA/ST landscape may include Confucian and dialectic modes, but it should also include Daoist and dialogic modes. (For a brief explanation of the difference between dialectic and dialogic, see Wikipedia: Dialogic.) Robust debate between dogmatic EA and dogmatic ST may lead to schism, but even that is preferable to bland and empty speech. If we want to have a serious discussion about the strengths and weaknesses of current practice, then we must be prepared for robust critique, and we should not have to worry about over-sensitive practitioners taking everything personally.

One possible aspiration is to build a bridge between two communities, or perhaps even one single community. In their presentation, Patrick Hoverstadt and Lucy Loh presented some recent work of the EAST working group, showing how the concepts and techniques of EA and ST could be combined to address business challenges. This work is ongoing.
If we take the view that community building depend on affiliation (finding common beliefs and values), then any schism and doubt may seem to undermine this agenda. However, there is a more robust path to community building, based on alliance (accepting and overcoming difference for the sake of collaboration). For an eloquent defence of what she calls Deep Disagreement, see Margaret Heffernan’s TED Talk Dare to Disagree.

Perhaps some people will think me perverse, but I look forward to plenty more friendly disagreement between EA and ST in future.

Schism and doubt

On Friday 14th June, there was a public meeting of the EAST group, entitled Perspectives on Enterprise Architecture and Systems Thinking, kindly hosted by BT in its offices near St Paul’s. Tom Graves has posted a detailed write-up on his blog At ‘EA and Systems-Thinking’ conference.

What is the purpose of dialogue between EA and ST? Putting aside the debate about what the labels “Enterprise Architecture” and “Systems Thinking” might mean, there is certainly a thought that the two (or more) communities can learn from each other. There are strengths and weaknesses on both sides – so we may be able to produce a critique of EA from an ST perspective, or a critique of ST from an EA perspective. For example, in his presentation, John Holland asserted that “EA is broken – How ST can help”. (See Tom’s blog for summary.)

This kind of material often arouses a certain kind of resistance. “He’s not talking about me, he must be talking about someone else.” Where are the EAs to whom such a criticism as John’s might apply? Surely the fact that we are going to these meetings, or reading these blogs, or participating in these Linked-In discussions, puts us into the most sophisticated and reflective quartile? 

One of the fundamental questions underlying discussion of EA and ST is imagining some kind of landscape with more or less distinct zones: EA over here, ST over there, this or that school of EA, this or that school of ST, good EA versus bad EA, authentic ST versus fake ST, mainstream versus next practice.

I have written several pieces on the relationship between Enterprise Architecture (EA) and Systems Thinking (ST), on this blog and elsewhere, but such pieces are always open to challenge by those who disagree about the correct use of the labels.

  • “That’s not what real Enterprise Architects do.”
  • “That’s not really Systems Thinking.”

So it sometimes seems that we cannot even start talking about EA and ST, and about the relationship (if any) between them, until we can agree what these terms mean. The desire to name things properly is an ancient one, and can be found in the Analects of Confucius. (See my post on the Wisdom of Confucius). But the prevailing desire to impose one’s own definitions leads to endless and mostly unproductive debate on Linked-In and elsewhere. For this meeting, we hoped for a more productive energy, and I like to think we largely succeeded.

Some of the speakers fell into a dialectic mode of presentation – on the one hand EA, on the other hand ST. This can be useful as a starting point, but if the distinction between EA and ST is taken too seriously it may drive a wedge between practitioners. As Tom commented, “there don’t seem to be any clear distinctions, any absolute boundaries that determine who’s ‘in’ and who’s ‘out’ – all a bit blurry all round, really.” For my part, instead of trying to avoid making any distinctions whatsoever, I put up a few slides with some provocative and playful distinctions, flagged with “possibly” and “tongue-in-cheek”. But I haven’t always been consistent about this, and (as someone pointed out to me) I probably need to be more careful when making a rhetorical contrast between “mainstream” and “next practice”.

The EA/ST landscape may include Confucian and dialectic modes, but it should also include Daoist and dialogic modes. (For a brief explanation of the difference between dialectic and dialogic, see Wikipedia: Dialogic.) Robust debate between dogmatic EA and dogmatic ST may lead to schism, but even that is preferable to bland and empty speech. If we want to have a serious discussion about the strengths and weaknesses of current practice, then we must be prepared for robust critique, and we should not have to worry about over-sensitive practitioners taking everything personally.

One possible aspiration is to build a bridge between two communities, or perhaps even one single community. In their presentation, Patrick Hoverstadt and Lucy Loh presented some recent work of the EAST working group, showing how the concepts and techniques of EA and ST could be combined to address business challenges. This work is ongoing.
If we take the view that community building depend on affiliation (finding common beliefs and values), then any schism and doubt may seem to undermine this agenda. However, there is a more robust path to community building, based on alliance (accepting and overcoming difference for the sake of collaboration). For an eloquent defence of what she calls Deep Disagreement, see Margaret Heffernan’s TED Talk Dare to Disagree.

Perhaps some people will think me perverse, but I look forward to plenty more friendly disagreement between EA and ST in future.

Speaking the Language of Business with TOGAF®

By Glenn Evans, Senior Consultant at Enterprise Architects I remember as a young child coming from a ‘non-sports obsessed’ family, I didn’t know what a yorker was, didn’t know what ‘LBW’ meant, or why Dennis Lillee or Geoffrey Boycott were … Continue reading

Enterprise Architecture driving Private Cloud adoption by U.S. Federal Government

Despite all the incumbent benefits offered to businesses that own and operate their own Private Cloud, adoption rates since its emergence have been slower than anticipated, especially across Government organisations. This is largely the result of repeated reports from experts warning against the associated security risks that come from placing sensitive data in cyber space. …

Read more

Link Collection — July 14, 2013

  • This Is the Woman at the Heart of Everything Google Builds | Wired Enterprise | Wired.com

    Interesting article on the tools built/used by Google developers, and the woman who oversees the dev tool team. For the tool insights, jump to “For Google Eyes Only”.

    “Google’s developer tools are, in some ways, a reflection of the egalitarian philosophy Meckfessel sees at play throughout the company. A single system, available from any company web browser, provides instant access to practically every piece of code that underpins practically every Google product and service. It even houses the code used to build, well, itself, in the kind of circular setup that’s so very common in the world of software.

    The result is any Google engineer can tinker with code built by any other Google engineer. “The code is completely open — within the company,” Meckfessel says.

    That doesn’t mean anyone can rewrite the code for, say, Gmail, compile it into executable software, and completely revamp the popular email service all on their own. But it does mean they can peruse and edit any of Gmail’s underlying code — and if they submit it to the right person for review and testing and compilation, they can indeed change the live service.”

    tags: google development

  • High Scalability – High Scalability – The Architecture Twitter Uses to Deal with 150M Active Users, 300K QPS, a 22 MB/S Firehose, and Send Tweets in Under 5 Seconds

    “Everybody has this idea that Twitter is easy. With a little architectural hand waving we have a scalable Twitter, just that simple. Well, it’s not that simple as Raffi Krikorian, VP of Engineering at Twitter, describes in his superb and very detailed presentation on Timelines at Scale. If you want to know how Twitter works – then start here.”

    tags: architecture twitter scale

  • The Body Data Craze – Newsweek and The Daily Beast

    Overview of the Quantified Self trend. 

    “Welcome to my biography, 2013-style. It includes more data points than it possibly could have 20 years ago. And it’s part of a national obsession of a people who, literally, number our days. According to a recent nationwide survey for Pew Research Center Internet & American Life Project, 7 out of 10 people self-track regularly—using everything from human memory to a memory stick—some aspect of health for themselves or for someone else. Among the 3,000 adults questioned, the most popular things to monitor were weight and diet. A third of the people surveyed also track more esoteric elements of their health, from blood pressure to sleep to blood sugar. While many of them keep this information “in their heads,” a full 50 percent actually keep a written record of the data either using technology or on paper. According to the Consumer Electronics Association, in 2012 the U.S. sports and fitness category was a $70 billion business; and earlier this year, market firm ABI released a report that estimated that 485 million wearable computing devices—like smart watches and smart glasses—will be shipped annually by 2018.””

    tags: quantifiedself

  • Irving Wladawsky-Berger: Big Data Takes Center Stage

    “The next change requires accepting messiness instead of insisting on clean, carefully curated data.  “[In] an increasing number of situations, a bit of inaccuracy can be tolerated, because the benefits of using vastly more data of variable quality outweigh the costs of using smaller amounts of very exact data. . . When there was not that much data around, researchers had to make sure that the figures they bothered to collect were as exact as possible.  Tapping vastly more data means that we can now allow some inaccuracies to slip in (provided the data set is not completely incorrect), in return for benefiting from the insights that a massive body of data provides.””

    tags: bigdata quality tolerance_continuum irvingwb

  • The Quantified Self: Fundamental Disruption in Big Data Science and Biological Discovery

    Research paper in Mary Ann Liebert, Big Data on Quantified Self. Big potential to aggregate individual data to make medical / biological discoveries and generate cures / remediations.

    “A key contemporary trend emerging in big data science is the quantified self (QS)–individuals engaged in the self-tracking of any kind of biological, physical, behavioral, or environmental information as n=1 individuals or in groups. There are opportunities for big data scientists to develop new models to support QS data collection, integration, and analysis, and also to lead in defining open-access database resources and privacy standards for how personal data is used. Next-generation QS applications could include tools for rendering QS data meaningful in behavior change, establishing baselines and variability in objective metrics, applying new kinds of pattern recognition techniques, and aggregating multiple self-tracking data streams from wearable electronics, biosensors, mobile phones, genomic data, and cloud-based services. The long-term vision of QS activity is that of a systemic monitoring approach where an individual’s continuous personal information climate provides real-time performance optimization suggestions. There are some potential limitations related to QS activity—barriers to widespread adoption and a critique regarding scientific soundness—but these may be overcome.”

    tags: bigdata healthcare quantifiedself

  • Micro Service Architecture

    “Micro Service Architecture is an architectural concept that aims to decouple a solution by decomposing functionality into discrete services. Think of it as applying many of the principles of SOLID at an architectural level, instead of classes you’ve got services.

    Conceptually speaking MSA is not particularly difficult to grasp but in practice it does raise many questions. How do these services communicate? What about latency between services? How do you test the services? How do you detect and respond to failure? How do you manage deployments when you have a bunch of interdependencies?”

    tags: architecture

Posted from Diigo. The rest of my favorite links are here.

Business Architecture & Enterprise Architecture – Match Made in Heaven

I recently spoke at the European BPM and EA Conference in London on this topic. This blog post is a summary version of my session.

Often Business Process Management and associated discipline such as Business Architecture is seen or managed in isolation of the overarching Enterprise Architecture construct. However the Business Architecture and Enterprise Architecture complement each other well to get the best value from each other. I think that the Business Architecture is one of the key enablers of the Enterprise Architecture and makes it real. While the Enterprise Architecture offers much needed context for the Business Architecture.

It might be useful to briefly review the definitions of both Business Architecture and Enterprise Architecture before understanding issues in their relationship. 

As I have been writing on this blog, Enterprise Architecture should not be limited to the IT or Technology concerns of an organisation. Rather it should be focused on addressing much broader scope covering the business, functional, operational, financial and people aspects of the enterprise. 

There are a number of Enterprise Architecture definitions out there. A couple of my favorite ones are as follows:


Enterprise Architecture provides a strategic planning framework that relates and aligns information technology with the business functions that it supports.


Or


Practice of enterprise architecture involves developing a framework to describe a series of “current”, “intermediate” and “target” reference architectures and applying them to align change within the enterprise. Another set of terms for these are “as-is”, “to-be” and the “migration plan”.



The Business Architecture Special Interest Group of Object Management Group (OMG) defines Business Architecture as follows:

“A Blueprint of the Enterprise That Provides A Common Understanding Of The Organization And Is Used To Align Strategic Objectives And Tactical Demands.”


“Business Architecture describes the product and/or service strategy, and the organizational, functional, process, information, and geographic aspects of the business environment”

I think that though the practice of both Business Architecture and Enterprise Architecture has matured over the past few years, there certainly are some issues when it comes to these two working well together. I have summarised them in four broad arguments;

  1. Business Architecture not done at all. Enterprise Architecture teams only perform Enterprise Technical Architecture only.
  2. Business Architecture done in isolation of Enterprise Technical Architecture and then (if lucky) artificially superimposed
  3. Business Architecture and Business Context Confusion: confusion between why, what and how
  4. Technology focused governance: only conversations about technical standards, business governance disconnected from IT investment and decisions leading to critical gaps
I have tried to capture this pictorially below:

BA & EA in Isolation

This issue is getting wider acknowledgment given its strategic importance. I particularly like Randy Heffner’s work in this space. He states in one of his blogs;

“Simply positioning business architecture as a layer on top of existing EA domains is a mistake. Traditionally many organisations have pursued EA as Enterprise Technical Architecture (ETA). ETA is technology-centred.  Business architecture is business-centred. Simply layering it on top of ETA will result in tech-centred silo implementation.”


As Business Architecture Special Interest Group of Object Management Group(OMG) states, the Business Architecture defines the structure of the enterprise in terms of its governance structure, business processes, and business information. In defining the structure of the enterprise, business architecture considers customers, finances, and the market to align strategic goals and objectives with decisions regarding products and services; partners and suppliers; organization; capabilities; and key initiatives. Business Architecture primarily should focus on the business motivations, business operations and business analysis frameworks and related networks that link these aspects of the enterprise together and it should be seamlessly integrated with Enterprise Architecture efforts within the organisation. 

In my experience to tackle above listed issues, following measures can be taken by the Architecture team;

  1. Business Architecture as part of Enterprise Architecture
  2. Business Architecture drives Enterprise Architecture domains
  3. Business Architecture and Business Context clarified and integrate
  4. Business aligned Technology governance


My pictorial representation from earlier changes as below now:


BA & EA in Collaboration

Modern Enterprise Architecture teams and Enterprise Architects can not longer afford to ignore the implications of Business Architecture. Likewise, modern business architects can no longer afford to work in isolation of organisation’s enterprise architecture. 

In conclusion of this article I would like to summarize my thoughts as follows:

  1. Enterprise Architecture in isolation of Business Architecture is simply Enterprise Technical Architecture
  2. Business Architecture should guide the development of Enterprise Architecture domains
  3. Business Architecture combined with Enterprise Architecture is a powerful tool for business-IT alignment
  4. Strategic Frameworks and Models help in achieving this alignment

And as Chris Potts would argue, the Chief Executive of an Organisation should be ultimately accountable for ensuring the two come together as we would expect him or her to be the Chief Enterprise Architect of the Enterprise!

For related articles:

Business Architecture & Enterprise Architecture – Match Made in Heaven

I recently spoke at the European BPM and EA Conference in London on this topic. This blog post is a summary version of my session.

Often Business Process Management and associated discipline such as Business Architecture is seen or managed in isolation of the overarching Enterprise Architecture construct. However the Business Architecture and Enterprise Architecture complement each other well to get the best value from each other. I think that the Business Architecture is one of the key enablers of the Enterprise Architecture and makes it real. While the Enterprise Architecture offers much needed context for the Business Architecture.

It might be useful to briefly review the definitions of both Business Architecture and Enterprise Architecture before understanding issues in their relationship. 

As I have been writing on this blog, Enterprise Architecture should not be limited to the IT or Technology concerns of an organisation. Rather it should be focused on addressing much broader scope covering the business, functional, operational, financial and people aspects of the enterprise. 

There are a number of Enterprise Architecture definitions out there. A couple of my favorite ones are as follows:


Enterprise Architecture provides a strategic planning framework that relates and aligns information technology with the business functions that it supports.


Or


Practice of enterprise architecture involves developing a framework to describe a series of “current”, “intermediate” and “target” reference architectures and applying them to align change within the enterprise. Another set of terms for these are “as-is”, “to-be” and the “migration plan”.



The Business Architecture Special Interest Group of Object Management Group (OMG) defines Business Architecture as follows:

“A Blueprint of the Enterprise That Provides A Common Understanding Of The Organization And Is Used To Align Strategic Objectives And Tactical Demands.”


“Business Architecture describes the product and/or service strategy, and the organizational, functional, process, information, and geographic aspects of the business environment”

I think that though the practice of both Business Architecture and Enterprise Architecture has matured over the past few years, there certainly are some issues when it comes to these two working well together. I have summarised them in four broad arguments;

  1. Business Architecture not done at all. Enterprise Architecture teams only perform Enterprise Technical Architecture only.
  2. Business Architecture done in isolation of Enterprise Technical Architecture and then (if lucky) artificially superimposed
  3. Business Architecture and Business Context Confusion: confusion between why, what and how
  4. Technology focused governance: only conversations about technical standards, business governance disconnected from IT investment and decisions leading to critical gaps
I have tried to capture this pictorially below:

BA & EA in Isolation

This issue is getting wider acknowledgment given its strategic importance. I particularly like Randy Heffner’s work in this space. He states in one of his blogs;

“Simply positioning business architecture as a layer on top of existing EA domains is a mistake. Traditionally many organisations have pursued EA as Enterprise Technical Architecture (ETA). ETA is technology-centred.  Business architecture is business-centred. Simply layering it on top of ETA will result in tech-centred silo implementation.”


As Business Architecture Special Interest Group of Object Management Group(OMG) states, the Business Architecture defines the structure of the enterprise in terms of its governance structure, business processes, and business information. In defining the structure of the enterprise, business architecture considers customers, finances, and the market to align strategic goals and objectives with decisions regarding products and services; partners and suppliers; organization; capabilities; and key initiatives. Business Architecture primarily should focus on the business motivations, business operations and business analysis frameworks and related networks that link these aspects of the enterprise together and it should be seamlessly integrated with Enterprise Architecture efforts within the organisation. 

In my experience to tackle above listed issues, following measures can be taken by the Architecture team;

  1. Business Architecture as part of Enterprise Architecture
  2. Business Architecture drives Enterprise Architecture domains
  3. Business Architecture and Business Context clarified and integrate
  4. Business aligned Technology governance


My pictorial representation from earlier changes as below now:


BA & EA in Collaboration

Modern Enterprise Architecture teams and Enterprise Architects can not longer afford to ignore the implications of Business Architecture. Likewise, modern business architects can no longer afford to work in isolation of organisation’s enterprise architecture. 

In conclusion of this article I would like to summarize my thoughts as follows:

  1. Enterprise Architecture in isolation of Business Architecture is simply Enterprise Technical Architecture
  2. Business Architecture should guide the development of Enterprise Architecture domains
  3. Business Architecture combined with Enterprise Architecture is a powerful tool for business-IT alignment
  4. Strategic Frameworks and Models help in achieving this alignment

And as Chris Potts would argue, the Chief Executive of an Organisation should be ultimately accountable for ensuring the two come together as we would expect him or her to be the Chief Enterprise Architect of the Enterprise!

For related articles:

Enterprise Architecture for Dummies

In part 8 of “Memoirs of an Enterprise Architect” I discussed how rationalizing your applications can allow you to do more with your organizational budget.  This week I would like to have an open dialog about Capabilities, Business Process, the Se…

Categories Uncategorized

Three laws of the next Internet of Things – the new platforming evolution in computing

By Mark Skilton, Global Director at Capgemini There is a wave of new devices and services that are growing in strength extending the boundary of what is possible in today’s internet driven economy and lifestyle.   A striking feature is the … Continue reading