Metadata as a Process

Data sharing and collaboration between different specialist areas requires agreement and transparency about the structure and meaning of the data. This is one of the functions of metadata.

I've been reading a paper (by Professor Paul Edwards and others) about the challenges this poses in interdisciplinary scientific research. They identify four characteristic features of scientific metadata, noting that these features can be found within a single specialist discipline as well as cross-discipline.

• Fragmentation - many people contributing, no overall control
  
• Divergent - multiple conflicting versions (often in Excel spreadsheets)
• Iterative - rarely right first time, lots of effort to repair misunderstandings and mistakes
• Localized - each participant is primarily focused on their own requirements rather than the global picture

They make two important distinctions, which will be relevant to enterprise data management as well.

Firstly between product and process. Instead of trying to create a static, definitive set of data definitions and properties, which will completely eliminate the need for any human interaction between the data creator and data consumer, assume that an ongoing channel of communication will be required to resolve emerging issues dynamically. (Some of the more advanced data management tools can support this.)

Secondly between precision and lubrication. Tight coupling between two systems requires exact metadata, but interoperability might also be achievable with inexact metadata plus something else to reduce any friction. (Metadata as the new oil, perhaps?)

Finally, they observe that metadata typically falls into the category of almost standards.

Everyone agrees they are a good idea, most have some such standards, yet few deploy them completely or effectively.

Does that sound familiar? 

---

J Bates, The politics of data friction (Journal of Documentation, 2017)

Paul Edwards, A Vast Machine (MIT Press 2010). I haven't read this book yet, but I found a review by Danny Yee (2011)

Paul Edwards, Matthew Mayernik, Archer Batcheller, Geoffrey Bowker and Christine Borgman, Science Friction: Data, Metadata and Collaboration (Social Studies of Science 41/5, October 2011), pp. 667-690. 

Martin Thomas Horsch, Silvia Chiacchiera, Welchy Leite Cavalcanti and Björn Schembera, Research Data Infrastructures and Engineering Metadata. In Data Technology in Materials Modelling (Springer 2021) pp 13-30

Jillian Wallis, Data Producers Courting Data Reusers: Two Cases from Modeling Communities (International Journal of Digital Curation, 2014, 9/1, 2014) pp 98–109

EA Effectiveness and Process Standardization

@tdegennaro of @Forrester spotted an interesting correlation in his company's 2009 survey. "Survey respondents who reported a high degree of business and IT process standardization also reported that EA was more effective and more influential within the organization."

DeGennaro suggests "there must be something that standardization does to an organization — a window or door that it creates — that enables IT functions such as EA to get better at what they do".

Is EA Effectiveness At The Mercy Of Process Standardization? (July 2010)

But there is another possible explanation for this correlation. According to DeGennaro, Forrester has convinced most of its clients that process standardization is a keystone to effectiveness across all areas of IT. If many EA practitioners are single-minded about process standardization, it is hardly surprising if these practitioners will be less successful in those organizations where process standardization isn't appropriate. Ross, Weill and Robertson ("Enterprise Architecture as Strategy") are among those who argue against a one-size-fits-all approach to EA. See my post on Differentiation and Integration (May 2010).

Correlations arising from surveys need to be carefully interpreted, to avoid circular reasoning masquerading as objective fact. I am always wary of industry analysts who are over-dependent on opinion surveys from their own customers and think that something must be true because their customers have swallowed it.

Differentiation and Integration 2

In my previous post on Differentiation and Integration, I mentioned the Operating Model propounded by Jeanne W. Ross, Peter Weill and David C. Robertson in their book Enterprise Architecture as Strategy (Harvard Business School Press 2006). I shall continue to refer to this book as RWR.

The publisher offers a pdf extract from the book, in which you will see the following diagram, depicting what RWR call a “traditional” approach to IT solutions. (It's a secure pdf, so I've had to scan my library copy instead.)

According to RWR, the “traditional” approach is characterized as follows

• Each strategic initiative results in a separate IT solution, each implemented on a different technology, producing a set of silos.
• The company’s data is patchy, error-prone, and not up-to-date.
• Companies often extract from silos to aggregate data from multiple systems in a data warehouse; but the warehouse is useful only as a reference – it does not offer real-time data across applications.

RWR cite a company whose systems were linked together so effectively that no human being ever touched a transaction (straight-through processing - sounds pretty integrated to me) but for some unspecified reason this provided “a lack of foundation for execution”.

Sounds like there is “good integration” and “bad integration”. Which brings us to the squiggles in the diagram. RWR appear to have adopted a notation in which “good integration” is denoted by straight lines and “bad integration” is denoted by squiggly lines. As far as I am aware, this notation has not been not formally defined, and is therefore purely a rhetorical device.

While I accept the need for enterprise architecture to create a powerful strategic narrative, I fear that these rhetorical devices permit and even encourage a kind of woolly uncritical thinking, which is not capable of dealing with the real challenges of enterprise strategy, and could easily be dismissed as intellectually lightweight by sharp CEOs presented with this kind of stuff. Vague diagrams with undefined notation are no substitute for proper analysis.

It doesn't matter how often the three characteristics identified by RWR above are found together, the key question is whether it is possible and practical to separate them. Is data sharing (as RWR believe) the only way to achieve “good integration”, or are (as I believe) other aspects of integration (coordination, organizational intelligence) more strategically important?

Contingency Theory

RWR identify two key questions for determining your organization’s strategy.

• To determine your organization’s integration requirements, ask yourself to what extent the successful completion of one business unit’s transactions is dependent on the availability, accuracy and timeliness of other business units’ data. (RWR p30)

• To determine your organization’s standardization requirements, ask yourself to what extent the company benefits by having business units run their operations in the same way. (RWR p30)

These would appear to be critical questions for enterprise architects to consider, so it would surely be useful to have some rigorous methods for analysing these questions systematically, instead of merely a few pen pictures of companies that have followed one or other path.

Furthermore, both questions seem to be questions of degree ("to what extent") rather than questions of kind (either/or) - so where are the examples of companies whose rightful place is half-way along the path, rather than at one or other extreme?

Differentiation

RWR then introduce the notion of strategic differentiation. "The operating model concept requires that management put a stake in the ground and declare which business processes will distinguish a company from its competitors." (RWR p43).

I find this statement puzzling, because there is no obvious connection between the two dimensions of the operating model identified by RWR (viz standardization and integration qua data sharing) and the idea of competitive differentiation.

There are methods that focus on identifying which business processes will distinguish a company from its competitors, such as the method developed by my former CBDI colleagues out of the ideas of Geoffrey Moore (see my post Tesco Outsources Core ECommerce) but this is not the same as the RWR method.

Shared Services

One way of achieving some kinds of standardization is through shared infrastructure. When talking about shared services, RWR implicitly shift the scope of “the enterprise” from a single organization to a partnership ecosystem.

“A strategic partnership forces a shared-services mentality, requiring business leaders to come to agreement on which services will be provided centrally and which will be provided locally.” (RWR p148)

The decision of which services will be provided centrally or locally is a matter of standardization, and therefore an aspect of enterprise-architecture-as-strategy.

Enterprise Architecture as Quantitative Practice

What I find troubling in many popular accounts of enterprise architecture, including RWR, is the apparent disregard for economics. RWR talk glibly about the costs and benefits of standardization, but they are not willing to explore the economies and diseconomies of scale, or the distribution of fixed and variable costs, and there isn't much meaningful quantification. Handwaving as strategy?

Differentiation and Integration

In my post on Business Design Choices, I suggested that the real challenge for business architecture was to appreciate the economic and social impact of structure. I identified some advanced business design choices where business architecture has a useful role to play, and where some IT people might have some relevant aptitude. In this post, I am going to expand on one of these.

---

Where does standardization make sense, and where should requisite variety be deployed? This question goes back to the work of Lawrence and Lorsch (L2), and has recently been rediscovered (in slightly different terms) by Ross, Weill and Robertson (RWR).

In their book Enterprise Architecture as Strategy, RWR define something they call an Operating Model, with two independent dimensions, business process standardization and integration. "Although we often think of standardization and integration as two sides of the same coin, they impose different demands. Executives need to recognize standardization and integration as two separate decisions." (p27)

Many people in the IT world take for granted that standardization (reduction in variety) is a good thing.  RWR acknowledge the benefits of standardization not only in terms of throughput and efficiency, but also predictability. However, they point out the potential downside of standardization both as a state (standardized processes limit local innovation) and as a state-change (politically difficult and expensive to rip out and replace perfectly good and occasionally superior systems and processes).

Integration, which RWR define primarily in terms of data sharing, is also assumed to be a good thing. RWR identify the benefits of integration in terms of efficiency, coordination, transparency and agility, and acknowledge the challenge of integration as a state-change in terms of "difficult, time-consuming decisions".

The two dimensions of standardization and integration produce a two-by-two matrix as follows.

Operating Model Quadrants (Adapted by Clive Finkelstein from Figure 2.3 of “Enterprise Architecture as Strategy”) - Source The Enterprise Newsletter #38.


Although RWR are careful to present a contingency theory of enterprise strategy, in which any of these four operating models may be strategically valid, the conventional rhetoric of the two-by-two matrix places the preferred strategy into the top right quadrant - thus Unification. Many enterprise architects from a traditional IT background may feel most comfortable with the Unification quadrant. (There may be a process of idealization here - see Schwartz.) Indeed, RWR go on to present an Enterprise Architecture Maturity Model, which starts with the easy bits of enterprise architecture (where things are already Unified) and ends with the challenging bits (where things are or should be Diversified).

---

L2 also identify two dimensions, which they call differentiation and integration. They tend to see increasing differentiation as a healthy response to increasing opportunity and complexity - a growing organization in a growing market - "faster change and greater heterogeneity" (p 235). Differentiation is not merely a difference in working practices, but includes at its core "the difference in cognitive and emotional orientation among managers in different functional departments" (p11).

Integration is then the administrative response to this increasing differentiation - how to maintain the overall coherence and viability of the enterprise as a whole. Integration is defined as "the quality of the state of collaboration that exists among departments that are required to achieve unity of effort by the demands of the environment" (p11). The topic of integration covers both the organizational state and the mechanisms to produce and support this state. For L2, the challenges of integration are not primarily IT related (data sharing) but personal and political (conflict resolution).

L2 don't offer a two-by-two matrix of Differentiation and Integration in their 1967 book (I guess the two-by-two matrix hadn't then established itself as an essential consultancy tool), but if they did then presumably the top-right quadrant would be High Differentiation, High Integration. This very roughly corresponds to what RWR call Coordination.

But in any case, a two-by-two matrix would be misleading. The point isn't to choose whether you have differentiation and integration or not; the point is to determine how much and what kinds of differentiation  and integration you need. L2 are explicit in their support of contingency theory (different strategies being appropriate for different organizations depending on environmental factors). The more complex and dynamic the environment, the greater the need for differentiation and integration.

If we are to take business architecture seriously as a discipline, then this kind of question is clearly central. In his post on Contingency Theory and Enterprise Architecture, Andy Blumenthal argues that contingency theory entails keeping your options open, but sometimes it just means making appropriate strategic choices. If the slogan "enterprise architecture as strategy" is to mean anything at all, then surely this is what it means.

---

Lawrence, P., and Lorsch, J., "Differentiation and Integration in Complex Organizations" Administrative Science Quarterly 12, (1967), 1-30. (see summary here)

Paul R. Lawrence and Jay W. Lorsch, Organization and Environment, Managing Differentiation and Integration. Harvard University 1967.

Jeanne W. Ross, Peter Weill and David C. Robertson, Enterprise Architecture as Strategy. Harvard Business School Press 2006.

Howard S. Schwartz, Narcissistic Process and Corporate Decay – The Theory of the Organizational Ideal. 1990. See his paper On the Psychodynamics of Organizational Disaster (Columbia Journal of World Business, Spring 1987) See also Joe Bormel's blogpost on Narcissism, Oxygen and HCIT Vision (June 2009).


Related posts

Business Design Choices (January 2010)
EA Effectiveness and Process Standardization (August 2012)

Business Design Choices

The SOA Consortium (part of the OMG) has published a Business Architecture Paper, edited by Brenda Michelson. The paper presents the following case for formalized Business Architecture under IT leadership.

1. Business architecture is a critical input to IT planning, technology architecture and business solution delivery.

2. Technology trends and IT capabilities influence business design choices in the realms of capabilities, value chains, processes, and channels.

3. Business architecture provides the mechanism to clearly illuminate how strategy, processes, business structure and staff can best be utilized to deliver reliable and cost effective operations. With this clarity business can enable new functions and services, with the right resources and technology, effectively and efficiently.

4. Business architecture can help organizations analyze key value chains. Organizations can eliminate duplicate operations, processes and technologies across business units and functions. Business architecture provides the methods to analyze and plan how the organization should morph its structure, processes, technology and staff.

5. The most likely origin of a business architecture practice is within IT.

It is difficult to see anything here that wasn't included in the Business Systems Planning and Business Engineering methodologies I first saw in the 1980s - for example, as a front-end to such methodologies as Information Engineering. Nowadays, Michael Porter's value chain concept is taught in high school business studies; so unless business managers are really thick, they are not going to need help from IT folk to "analyse key value chains".


Actually, there are some more advanced business design choices where business architecture has a useful role to play, and where some IT people might have some relevant aptitude, but the SOA Consortium doesn't mention any of these. I see the real challenge for business architecture being to appreciate the economic and social impact of structure. And by structure, I don't just mean the kind of line-and-box diagram or simplistic block diagram that most so-called architects produce, whether in PowerPoint or some cheap modelling tool, but something that reflects the real complexity of the business.



So what are these "business design choices" then? Well, this is a topic I've been talking about for many years, going back to my 2001 book on the Component-Based Business. Here are some critical ones, all of which I've discussed on this blog before, as well as in articles for the CBDI Journal.

1. Coupling. Which "components" of the business need to be closely aligned (tightly coupled) and which "components" should be autonomous (loosely coupled)? How is an enterprise governed as a system-of-systems? How do we reason about the properties of the whole enterprise?


2. Differentiation and Integration. Where does standardization make sense, and where should requisite variety be deployed? This question goes back to the work of Lawrence and Lorsch (see summary here), and has recently been rediscovered (in slightly different terms) in the book Enterprise Architecture and Strategy.

 

Operating Model Quadrants - Source MIT CISR.

3. Business as a Platform. A business provides a set of services to its customers. There is a strategic choice between a high-volume generalized platform, which takes a small slice of a large amount of activity, and a lower-volume specialized platform, which takes a much larger slice of a relatively smaller amount of activity. So for example, how does a telecoms company create value-adding services on top of the basic calling services (which are getting continually cheaper, thus eroding core revenue) without losing the economics of scale.

4. Edge Organization. What are the structural implications of turning your business upside-down and inside-out to address the dynamics of the demand environment?

5. Viable Business. What structures are required to support the intelligent organization?


So there is a set of really interesting and important issues here, which some of the smarter business people in the more complex industry sectors (aerospace, telecoms) are already trying to tackle. There are some new and emerging techniques for tackling these complex problems, including Asymmetric Design, as well as some older but underused techniques. However, I don't yet see much evidence of enterprise architects stepping up to the real challenges of business architecture.


Related Post: Differentiation and Integration (May 2010)

Has EA gone for a Burton?

@mikerollings, an analyst with the Burton Group, invited Brenda Michelson to check out his free report Enterprise Architecture is more than Engineering, so I thought I'd take up his invitation as well.

Mike Kavis had started the discussion with a comment on Twitter: "Everybody is struggling with the value of EA for us little guys while I see it each day." In reply, Brenda had suggested that the problem was "many equate EA w/jumbo frameworks and rigid governance, rather than set of values and practices for capability delivery". This was what prompted Mike Rollings to issue the invitation.

Meanwhile, Aleks Buterman claims to have a "secret sauce to measuring value of EA" but won't let anyone see the recipe. I think this is a pity, because I believe a credible measurement formula needs to be open, transparent and calibrated on a range of different organizations. I hope he's working towards making something public.

Before we look at Mike Rollings' own report on EA, let's take a quick look at his criticism of Gartner, provocatively entitled Gartner wakes out of an EA induced coma ... (11 August 2009)

"Thank you Gartner for validating my claim that prevailing wisdom about EA is washed up and the pursuit of building an EA admiration society is not the predominant goal of EA.  Thank you for further illustrating that living in a mythical world where EA is king is just dead wrong."

And he continues with a plug for his own firm

"Want a new approach for enterprise architecture? Read Burton Group's EA research."

So I did (see edited highlights below). Mike's report identifies three familiar problems, and then makes four fairly bland recommendations. Is this really a new approach? Unfortunately, there is a "disconnect" (one of Mike's favourite words) between these two sections, so the recommendations don't demonstrably deal with the problems. (Indeed, readers with real experience of EA may see ways in which Mike's recommendations might make some of his problems worse. For example, there are several plausible arguments for having an eclectic approach to EA, but it isn't clear how this is going to solve the problem of disconnected EA artifacts.)

While Mike's understanding of EA problems appear to be underpinned by his adhoc observations of EA in practice, there is no sign that his recommendations are based on anything more than common sense. Therefore nothing to stop him, when he is arguing with Gartner, coming up with an entirely new set of recommendations (see below).

In my opinion EA is in crisis, and it needs a lot more than disconnected recommendations based on common sense and/or prevailing wisdom. More than engineering perhaps, but where is the value proposition for Enterprise Architecture?

---

Edited highlights of Burton report

Problems facing EA

• EA has minimal influence. I have spoken with teams that could not gain traction - their artifacts were disconnected from each other and lacked relevant guidance. I have also seen beautiful architectures ... that go unused.
  

• Lack of participation and commitment. A lack of participation can fuel and be perceived as the ivory tower syndrome, which is a natural outcome of organizational isolation.
  

• Mismatch with the domains of the effective CIO. Most EA programs are heavily skewed towards a single domain: implementing and managing technology.
  

Burton recommendations

• Avoid using frameworks like a precise cookbook for architecture. A variety of methods (unspecified) should be used to capture, communicate and share design information. Enterprise architects employ both manual and mechanical tools in a purposeful way.
  

• Align with your organization's operating model. The operating model is fundamental to the business. Effective EA programs align with the operating model and do not over-reach the level of standardization or integration determined by the business.
  

• Be results-oriented. Successful EA programs are action-oriented and help get things done. People understand how the EA program works. They also understand the contribution that EA team members make as participants in other IT processes.
  

• Do not settle for comparisons: Understand what needs to improve. Maturity assessments can be very elaborate. At a minimum they should evaluate the following EA program characteristics: Business Alignment, EA Program Oversight, Communication and Change Leadership, and Governance. By examining these characteristics with an open mind toward change, an improvement plan can be created to improve EA related outcomes.

New recommendations (Mike Rollings via InfoQ, 26 August 2009)

• Rule-Breaking: If rules are being broken it can signal outdated thinking and the need for something different.
  

• Entrepreneurial: Value of IT comes from being transparent about your business contribution.
  

• Self-Educating: Embrace varying ideas, collaborate vigorously and respectfully, assure that you tap into the variety of perspectives that exist. 
  

• Bonding: The lack of influence is probably a main cause of your EA coma.
  

• Visionary: Be a leader, be a team player, participate and collaborate.

---

Update: Burton Group gone for a Burton

The Burton Group was acquired by Gartner in January 2010. Mike Rollings is now a Gartner Analyst.

Ford and Fordism

In his piece Flashlights not Bailouts, Phil Gilbert describes the classic CBD/SOA argument: standardization/rationalization/reuse.

"One of the three (Ford) is in demonstrably better shape than the other two, and it's no mystery why. Two years ago, when he took the reins of Ford, Alan Mulally identified two things that needed to change: parts costs have to go down, and engineering productivity must go up."

"Get it? The white collar workers who design the cars have to move from artisan to engineer, and they need to work together across all the company's platforms to use common parts."

I asked Phil if this was Fordism? Phil responded thus:

"Ford used standardization of task to drive down costs. I'm suggesting 'standardization' of transparency to drive down risk."

Thus Fordism progresses from the economics of scale to the economics of governance. This fits well with the story about SOA I've been telling in this blog. http://tinyurl.com/d3ronn

Metropolis

In a piece called Metropolis, published in the Microsoft Architecture Journal, Microsoft guru Pat Helland has written about the relationship between service-oriented networks and cities

Helland's article makes the following argument.

1. Progress requires standardization. (According to Helland, people didn't even wash properly until they had standard clothing.)
2. Standardization is associated with commoditization.
3. Standardization requires concentration of power (and if this involves pathological distortions of socioeconomic relations, such as WalMart or dare we say it Microsoft, so be it).
4. Infrastructure requires central investment. (Since we may regard infrastructure as an act of local standardization, it follows that it must involve concentration of power.)
5. Central investment preserves the "sacred".

I was however surprised that he does not mention the work of Christopher Alexander - especially his 1987 book A New Theory of Urban Design. Given the influence that Alexander's earlier books on structure and patterns have had on the software engineering community, it is amazing how few people in this community have read his later work.

The analogy between computer networks and cities has also been explored by the mathematician Nikos A. Salingaros. See especially his piece on the Information Architecture of Cities. Further comments by Phil Jones.

For more commentary on Helland's piece see the Newswire on Service-Based Design by my colleague David Sprott (CBDI Forum) no longer available.

See also Peter Lindberg's blog.

---

Update: Following this post, Philip Boxer and I wrote two articles for the Microsoft Architecture Journal.

Metropolis and SOA Governance: Towards the Agile Metropolis (Architecture Journal 5, July 2005)

Taking Governance to the Edge (Architecture Journal 6, August 2006)

Related post: SOA and Holism (January 2009), Christopher Alexander 1936-2022 (March 2022)