Archive for the ‘Best Practice’ Category
Six heresies for enterprise architecture
Introduction
In a recent article in Forbes, Jason Bloomberg asks if Enterprise Architecture (EA) is “completely broken”. He reckons it is, and that EA frameworks, such as TOGAF and the Zachman Framework, are at least partly to blame. Here’s what he has to say about frameworks:
EA generally centers on the use of a framework like The Open Group Architecture Framework (TOGAF), the Zachman Framework™, or one of a handful of others. Yet while the use of such frameworks can successfully lead to business value, [they] tend to become self-referential… that [Enterprise Architects end up] spending all their effort working with the framework instead of solving real problems.
From experience, I’d have to agree: many architects are so absorbed by frameworks that they overlook their prime imperative, which is to deliver tangible value rather than pretty diagrams.
In this post I present six (possibly heretical!) practices that underpin an evolutionary or emergent approach to enterprise architecture. I believe that these will go some way towards addressing the issues that Bloomberg and others bemoan.
The heresies
Here are they are, in no particular order:
1. Use an incremental approach
As Bloomberg notes in the passage above, many enterprise architects spend a great deal of their time creating blueprints and plans based on frameworks. The problem is, this activity rarely leads to anything of genuine business value because blueprints or plans are necessarily:
- Incomplete – they are high-level abstractions that omit messy, ground-level details. Put another way, they are maps that should not be confused with the territory.
- Static – they are based on snapshots of an organization and its IT infrastructure at a point in time. Even roadmaps that are intended to describe how organisations’ processes and technologies will evolve in time are, in reality, extrapolations from information available at a point in time.
The straightforward way to address this is to shun big architectures upfront and embrace an iterative and incremental approach instead. The Agile movement has shown the way forward for software development. There are many convincing real-life demonstrations of the use of agile approaches to enterprise-scale initiatives (Ralph Hughes’ approach to Agile data warehousing, for example). Such examples suggest that the principles behind agile software development can be fruitfully adapted to the practice of enterprise architecture.
The key principle is to start as small as possible and scale-up from there. Such an approach would enable architects to learn along the way, giving them a better chance of getting their heads around those messy but important details that get overlooked when one considers the entire enterprise upfront. Another benefit is that it would give them adequate time to develop an awareness of the factors that are prone to change frequently and those that will remain relatively static. Most important, though, is that it would offer several opportunities to correct errors and fine tune things at little extra cost.
2. Understand the unique features of your organisation
Enterprise architects tend to be people with a wide experience in technology. As a result they are often treated (and see themselves) as experts. The danger of this attitude is that it can lead them to believe that they have privileged insights into the ills of their organizations. A familiarity with frameworks tends to reinforce this view because frameworks, with their focus on standardization, tend to emphasise the common features of organisations. However, I believe that instead of focusing on similarities an enterprise architect would be better served by focusing on differences – the things that make his or her organisation unique. Only when one develops an understanding of differences can one start to build an architecture that actually supports the organization.
To be sure, there are structures and processes that are common to many organisations (for example, functions such as 1st level support or expense reimbursement processes) and these could potentially benefit from the implementation of standardized designs / practices. However, the identification of such commonalities should be an outcome of research rather than an upfront assumption. And this requires ongoing, open dialogue with key stakeholders in the business (more on that later)
3. Form your own opinions about what works and what doesn’t
The surfeit of standardized “best practice” approaches to EA tends to make enterprise architects intellectually lazy. This is actually a symptom of a wider malaise in IT: I have noticed that professionals in the upper echelons of IT are happy to “outsource their thinking” by following someone else’s advice or procedures without much thought. The problem with this attitude, penalty clauses notwithstanding, is that one cannot “outsource the blame” when things go wrong.
I therefore believe one of the key attributes of a good architect is to develop a critical attitude towards frameworks, “best practices” and even consulting advice (especially if it comes from a Big 4 consultancy or guru). If you’re really as experienced as you claim to be, you need to develop your own opinions of what works and what doesn’t and be willing to subject those opinions to scrutiny by others.
4. Understand your organisation’s constraints
Humans tend to be over-optimistic when it comes to planning: witness the developer who blithely tells his boss that it will take a week to do a certain task…and then takes a month because of problems he had not anticipated. Similarly, many architects create designs that look great on paper but are not realistic because they have overlooked potential organizational constraints. Examples of such constraints include:
- Top-down reporting structures in which all decisions have to be made or approved by top management.
- Rigid organizational hierarchies that discourage cross-functional communication and collaboration.
Although constraints can also be technical (such as the limitations of a particular technology), the above examples illustrate that organizational constraints are considerably harder to address, primarily because they involve changing behaviour of influential people within the organization.
Architects lack the positional authority to do anything about such constraints directly. However, they need to develop an understanding of the main constraints so that they can bring them to the attention of those who can do something about them.
5. Focus on problem finding rather than problem solving
In his book, Management in Small Doses, Russell Ackoff wrote that in the real world problems are seldom given; they must be taken. This is good advice for enterprise architects to live by. Indeed, one of the shortcomings of frameworks is that they tend to present the architect with ready-made problems – specifically, any process or technology that does not comply with the framework is seen as a problem. Consequently, many architects spend considerable effort in fixing such “deviations”. However, non-conforming processes or technologies are seldom the most pressing problems that the organization faces. Instead, an enterprise architect will be better served by of finding problems that actually need fixing.
6. Understand the social implications of enterprise architecture
Enterprise architecture is seen as a primarily technical undertaking. As a result architects often overlook the social implications of their designs. Here are a couple of common ways in which this happens:
- Enterprise architecture invariably involves trade-offs. When evaluating these, architects typically focus on economic variables such as cost, productivity, efficiency, throughput etc., ignoring human factors such as ease of use and user preferences.
- Any design choice will (usually) benefit certain stakeholders while disadvantaging others.
Architects need to remember that their plans and designs are going to change the way people work. Nobody likes change without consultation, so it critical to seek as wide a spectrum of opinions as possible before making important design decisions. One can never satisfy everyone, but one has a better chance of making sensible compromises if one knows where all the stakeholders stand.
In closing
To summarise: enterprise architects need to take an emergent approach to design. Such an approach proceeds in an incremental fashion, pays due attention to the unique features and constraints of an organization, focuses on real rather than imagined problems…and, above all, acknowledges that the success or failure of enterprise architecture rests neither on frameworks nor technology, but on people. My (admittedly limited) experience suggests that such an approach would be more fruitful than the framework-driven approaches that have come to dominate the profession.
Six heresies for business intelligence
What is business intelligence?
I recently asked a few acquaintances to answer this question without referring to that great single point of truth in the cloud. They duly came up with a variety of responses ranging from data warehousing and the names of specific business intelligence tools to particular functions such as reporting or decision support.
After receiving their responses, I did what I asked my respondents not to: I googled the term. Here are a few samples of what I found:
According to CIO magazine, Business intelligence is an umbrella term that refers to a variety of software applications used to analyze an organization’s raw data.
Wikipedia, on the other hand, tells us that BI is a set of theories, methodologies, architectures, and technologies that transform raw data into meaningful and useful information for business purposes.
Finally, Webopedia, tell us that BI [refers to] the tools and systems that play a key role in the strategic planning process of the corporation.
What’s interesting about the above responses and definitions is that they focus largely on processes and methodologies or tools and techniques. Now, without downplaying the importance of either, I think that many of the problems of business intelligence practice come from taking a perspective that is overly focused on methodology and technique. In this post, I attempt to broaden this perspective by making some potentially controversial statements –or heresies – that challenge this view. My aim is not so much to criticize current practice as to encourage – or provoke – business intelligence professionals to take a closer look at some of the assumptions underlie their practices.
The heresies
Without further ado, here are my six heresies for business intelligence practice (in no particular order).
A single point of truth is a mirage
Many organisations embark on ambitious programs to build enterprise data warehouses – unified data repositories that serve as a single source of truth for all business-relevant data. Leaving aside the technical and business issues associated with establishing definitive data sources and harmonizing data, there is the more fundamental question of what is meant by truth.
The most commonly accepted notion of truth is that information (or data in a particular context) is true if it describes something as it actually is. A major issue with this viewpoint is that data (or information) can never fully describe a real-world object or event. For example, when a sales rep records a customer call, he or she notes down only what is required by the customer management system. Other data that may well be more important is not captured or is relegated to a “Notes” or “Comments” field that is rarely if ever searched or accessed. Indeed, data represents only a fraction of the truth, however one chooses to define it – more on this below.
Some might say that it is naïve to expect our databases to capture all aspects of reality, and that what is needed is a broad consensus between all relevant stakeholders as to what constitutes the truth. The problem with this is that such a consensus is often achieved by means that are not democratic. For example, a KPI definition chosen by a manager may be hotly contested by an employee. Nevertheless, the employee has to accept it because that is the way (many) organisations work. Another significant issue is that the notion of relevant stakeholders is itself problematic because it is often difficult to come up with clear criterion by which to define relevance.
There are other ways to approach the notion of truth: for example, one might say that a piece of data is true as long as it is practically useful to deem it so. Such a viewpoint, though common, is flawed because utility is in the eye of the beholder: a sales manager may think it useful to believe a particular KPI whereas a sales rep might disagree (particularly if the KPI portrays the rep in a bad light!).
These varied interpretations of what constitute a truth have implications for the notion of a single point of truth. For one, the various interpretations are incommensurate – they cannot be judged by the same standard. Further, different people may interpret the same piece of data differently. This is something that BI professionals have likely come across – say when attempting to come up with a harmonized definition for a customer record.
In short: the notion of a single point of truth is problematic because there is a great deal of ambiguity about what constitutes a truth.
There is no such thing as raw data
In his book, Memory Practices in the Sciences, Geoffrey Bowker wrote, “Raw data is both an oxymoron and a bad idea; to the contrary, data should be cooked with care.” I love this quote because it tells a great truth (!) about so-called “raw” data.
To elaborate: raw data is never unprocessed. Firstly, the data collector always makes a choice as to what data will be collected and what will not. So in this sense, data already has meaning imposed on it. Second, and perhaps more important, the method of collection affects the data. For example, responses to a survey depend on how the questions are framed and how the survey itself is carried out (anonymous, face-to-face etc.). This is also true for more “objective” data such as costs and expenses. In both cases, the actual numbers depend on specific accounting practices used in the organization. So, raw data is an oxymoron because data is never raw, and as Bowker tells us, we need to ensure that the filters we apply and the methods of collection we use are such that the resulting data is “cooked with care.”
In short: data is never raw, it is always “cooked.”
There are no best practices for business intelligence, only appropriate ones
Many software shops and consultancies devise frameworks and methodologies for business intelligence which they claim are based on best or proven practices. However, those who swallow that line and attempt to implement the practices often find that the results obtained are far from best.
I have discussed the shortcomings of best practices in a general context in an earlier article, and (at greater length) in my book. A problem with best practice approaches is that they assume a universal yardstick of what is best. As a corollary, this also suggest that practices can be transplanted from one organization to another in a wholesale manner, without extensive customisation. This overlooks the fact that organisations are unique, and what works in one may not work in another.
A deeper issue is that much of the knowledge pertaining to best practices is tacit – that is, it cannot be codified in written form. Indeed, what differentiates good business intelligence developers or architects from great ones is not what they learnt from a textbook (or in a training course), but how they actually practice their craft. These consist of things that they do instinctively and would find hard to put into words.
So, instead of looking to import best practices from your favourite vendor, it is better to focus on understanding what goes on in your environment. A critical examination of your environment and processes will reveal opportunities for improvement. These incremental improvements will cumulatively add up to your very own, customized “best practices.”
In short: develop your own business intelligence best practices rather than copying those peddled by “experts.”
Business intelligence does not support strategic decision-making
One of the stated aims of business intelligence systems is to support better business decision making in organisations (see the Wikipedia article, for example). It is true that business intelligence systems are perfectly adequate – even indispensable – for certain decision-making situations. Examples of these include, financial reporting (when done right!) and other operational reporting (inventory, logistics etc). These generally tend to be routine situations with clear cut decision criteria and well-defined processes – i.e. decisions that can be programmed.
In contrast, decisions pertaining to strategic matters cannot be programmed. Examples of such decisions include: dealing with an uncertain business environment, responding to a new competitor etc. The reason such decisions cannot be programmed is that they depend on a host of factors other than data and are generally made in situations that are ambiguous. Typically people use deliberative methods – i.e. methods based on argumentation – to arrive at decisions on such matters. The sad fact is that all the major business tools in the market lack support for deliberative decision-making. Check out this post for more on what can be done about this.
In short: business intelligence does not support strategic decision-making .
Big data is not the panacea it is trumpeted to be
One of the more recent trends in business intelligence is the move towards analyzing increasingly large, diverse, rapidly changing datasets – what goes under the umbrella term big data. Analysing these datasets entails the use of new technologies (e.g. Hadoop and NoSQL) as well as statistical techniques that are not familiar to many mainstream business intelligence professionals.
Much has been claimed for big data; in fact, one might say too much. In this article Tim Harford (aka the Undercover Economist) summarises the four main claims of “big data cheerleaders” as follows (the four phrases below are quoted directly from the article):
- Data analysis produces uncannily accurate results.
- Every single data point can be captured, making old statistical sampling techniques obsolete.
- It is passé to fret about what causes what, because statistical correlation tells us what we need to know.
- Scientific or statistical models aren’t needed.
The problem, as Harford points out, is that all of these claims are incorrect.
Firstly, the accuracy of the results that come out of a big data analysis depend critically on how the analysis is formulated. However, even analyses based on well-founded assumptions can get it wrong, as is illustrated in this article about Google Flu Trends.
Secondly, it is pretty obvious that it is impossible to capture every single data point (also relevant here is the discussion on raw data above – i.e. how data is selected for inclusion).
The third claim is simply absurd. The fact is detecting a correlation is not the same as understanding what is going on – a point made rather nicely by Dilbert. Enough said, I think.
Fourthly, the claim that scientific or statistical models aren’t needed is simply ill-informed. As any big data practitioner will tell you, big data analysis relies on statistics. Moreover, as mentioned earlier, a correlation-based understanding is no understanding at all – it cannot be reliably extrapolated to related situations without the help of hypotheses and (possibly tentative) models of how the phenomenon under study works.
Finally, as Danah Boyd and Kate Crawford point out in this paper , big data changes the meaning of what it means to know something….and it is highly debatable as to whether these changes are for the better. See the paper for more on this point. (Acknowledgement: the title of this post is inspired by the title of the Boyd-Crawford paper).
In short: business intelligence practitioners should not uncritically accept the pronouncements of big data evangelists and vendors.
Business intelligence has ethical implications
This heresy applies to much more than business intelligence: any human activity that affects other people has an ethical dimension. Many IT professionals tend to overlook this facet of their work because they are unaware of it – and sometimes prefer to remain so. Fact is, the decisions business intelligence professionals make with respect to usability, display, testing etc. have a potential impact on the people who use their applications. The impact may be as trivial as having to click a button or filter too many before they get their report, to something more significant, like a data error that leads to a poor business decision.
In short: business intelligence professionals ought to consider how their artefacts and applications affect their users.
In closing
This brings me to the end of my heresies for business intelligence. I suspect there will be a few practitioners who agree with me and (possibly many) others who don’t…and some of the latter may even find specific statements provocative. If so, I consider my job done, for my intent was to get business intelligence practitioners to question a few unquestioned tenets of their profession.
The architect and the apparition – a business fable
Sean yawned as he powered down his computer and stretched out in his chair. It was nearly 3 am and he had just finished proofreading his presentation for later that day. He didn’t remember ever being this tired; a great deal of effort had been expended over the last three months but it had been worth it. Now, finally, he was done.
He gazed down at the beautifully bound document on his desk with a fondness that lesser mortals might bestow on their progeny.
“That’s a fine looking document you have there,” said an oddly familiar voice from right behind his chair.
“Wha..,” squeaked Sean, shooting out of his chair, upending his coffee mug in the process.
He grabbed a couple of tissues and dabbed ineffectually at the coffee stain that was spreading rapidly across the front of his brand new chinos. “Damn,” he cursed as he looked up to find himself face-to-face with someone who looked just like him – right down to the Ralph Lauren shirt and Chinos (minus the unseemly stain).
“Pardon me,” sputtered the apparition, giving in to a fit of laughter. “That’s funniest thing I’ve seen in a long time, a scene worthy of million YouTube hits. You should’ve seen yourself jump out the chair and…”
“Pardon my rudeness, but who the f**k are you?” interrupted Sean, a tad testily. Who did this guy think he was anyway? (Lest you get the wrong idea, Sean didn’t normally use expletives, but he reckoned the situation merited it.)
“Don’t swear at me,” said the double, “because I am you…well, your conscience actually. But, in the end I’m still you.”
“Bah,” replied Sean. He figured this had to be a prank hatched by one of his workmates. “Tell me which one of my smartarse colleagues put you up to this?” he demanded, “Let me guess; it is either Mal or Liz.”
“You don’t believe me, do you? No one put me up to this. Well actually, if anyone did, it was you!”
“That’s nonsense,” spat Sean, his blood pressure rising a notch, “I have no idea who you are.”
“Ah, now we get to the nub of the matter,” said the apparition, “You have no idea who I am, and that is precisely why I’m here: to remind you that I exist and that you should listen to me from time to time. I usually start to bother you when you’re are about to do something stupid or unethical.”
“Me? Stupid? Unethical? I have no idea what you’re on about,” contested Sean.
“It appears I need to spell out for you. Well here’s the executive summary: I think you need to revise that document you’ve been working on. I’m your conscience, and I think I can help.”
“I… don’t… need… your… help,” said Sean enunciating each word exaggeratedly for emphasis, “you probably do not know this, but I have completed the biggest and most ambitious design I’ve ever done: a comprehensive systems architecture for Big Enterprise. I’m confident of what I have proposed because it is backed by solid research and industry best practice.”
“I know what you have done,” said the doppelganger, “I’m your conscience, after all.” He paused to clear his throat. “And I’m sure you believe what you have written, “he continued, “but that doesn’t make it right.”
“It is impeccably researched! You know, I’ve cited over 800 references, yeah eight hundred,” said Sean with pride. “That’s over two references per page, and most of these are to works written by acknowledged experts in the field.”
“I do not doubt your knowledge or diligence, my friend,” said the doppelganger with a smile, “what I worry about is your judgement.”
Sean was ready to blow a fuse, but was also confused (intrigued?) by the double’s choice of words. “Judgement?” he blurted, “WTF do you mean by ‘judgement?” He picked up the tome and waved it in front of the doppelganger imperiously…but then spoilt the effect by almost spraining his wrist in the process. He put the book down hurriedly saying, “this is an objective evaluation; the facts speak for themselves.”
“Do they?” queried the apparition. Sure, you’ve collected all this information and have fashioned into a coherent report. However, your recommendations, which appear to be based on facts, are in truth based on unverifiable assumptions, even opinions.”
“That’s nonsense,” dismissed Sean. “You haven’t even read the report, so you’re in no position to judge.”
“I have. I’m your conscience, remember?”
“Pah!”
“OK, so tell me what you did and how you did it,” said the apparition evenly.
Sean held forth for a few minutes, describing how he researched various frameworks, read case studies about them and then performed an evaluation based on criteria recommended by experts.
“I concede you that you truly believe you are right, but the sad fact is that you probably aren’t,” said the double, “and worse, you refuse to entertain that possibility.”
“That’s hogwash! If you’re so sure then prove it,” countered Sean.
“Hmmm, you are thicker than I thought, let me see if I can get my point across in a different way,” said the double. “You’re doing something that will influence the future of technology in your organisation for a long time to come. That is an immense responsibility…”
“I’m aware of that, thank you,” interrupted Sean, raising his voice. He’d had enough of this presumptuous, insulting clown.
“If you say so,” said the doppelganger, “but, to be honest, I sense no doubts and see no caveats in your report.”
“That’s because I have none! I believe in and stand by what I have done,” shouted Sean.
“I have no doubt that you believe in what you have done. The question is, do others, will others?”
“I’m not stupid,” said Sean, “I’ve kept my managers and other key stakeholders in the loop throughout. They know what my recommendations are, and they are good with them.”
“How many stakeholders, and where are they located?”
“Over ten important stakeholders, senior managers, all of them, and all seated right here in the corporate head office,” said Sean. He made to pick up the tome again, but a twinge in his wrist reminded him that it might not be wise to do so. “Let me tell you that the feedback I have from them is that this is a fantastic piece of work,” he continued, emphasizing his point by rapping on the wrist-spraining tome with his knuckles. “So please go away and leave me to finish up my work.”
“Yeah, I’ll go, it seems you have no need of me,” said the double, “but allow me a couple of questions before I go. I am your conscience after all!”
“Ok, what is it?” said Sean impatiently. He couldn’t wait to see the back of the guy.
“You’re working in a multinational right? But you’ve spoken to a few stakeholders all of whom are sitting right here, in this very building. Have you travelled around and spoken with staff in other countries – say in Asia and Europe – and gotten to know their problems before proposing your all-embracing architecture?”
“Look,” said Sean, “it is impossible to talk to everyone, so, I have done the best I can: I have proposed a design that adheres to best practices, and that means my design is fundamentally sound,” asserted Sean. “Moreover, the steering committee has reviewed it, and has indicated that it will be approved.”
“I have no doubt that it will be approved,” said the apparition patiently, “the question is: what then? Think about it, you have proposed an architecture for your enterprise without consulting the most important stakeholders – the people who will actually live it and work with it. Would you have an architect build your house that way? And how would you react to one who insisted on doing things his or her way because it is “best practice” to do so?”
“That’s a completely inappropriate comparison,” said Sean.
“No it isn’t, and you know it too” said the doppelganger. “But look, I’ve nothing more to add. I’ve said what I wanted to say. Besides, I’m sure you’re keen to see the back of me…most people are.”
…and pfft…just like that, the apparition vanished, leaving a bemused architect and a rapidly drying coffee stain in its wake.
Eight to Late 