EA the DNA Way

Reader ROI

• The importance of culture and behaviour in driving the IT agenda
• Why a DNA approach to EA allows the architect to plan for business agility
• How to establish structures and processes that reflect both business imperatives and the culture of an organization

In all the world's religious cultures, particularly the most extreme, every adherent knows exactly what constitutes acceptable behaviour. There is usually a rigid hierarchy, and everyone shares a language, set of ideas and beliefs, customs, taboos, codes, rituals and ceremonies. Typically, the culture was defined so long ago that no living person has any real idea how the habits and practices now considered the norm evolved. And typically, that does not matter one whit, because everyone knows what they need to know: if they move beyond those norms they will be ostracized.

Culture, in that sense, is all about behaviour. And very often, like dead high priestesses or archbishops, the people who most strongly defined that social architecture have long departed, even as their legacy lingers on in rigid codes of behaviour, cumbersome processes and the clunky, outmoded software installed to facilitate those processes.

Simon Shapiro, a CIO with international specialist banking group Investec, has come to think that most organizations are not unlike those rigid religions. People come into the organization from all walks of life, backgrounds and experience. Over time they collectively, even individually, negotiate patterns of acceptable social behaviour. Those patterns eventually crystallize into the hard core, the DNA if you like, of the organization. They define who people are and the roles they are allowed to play; how decisions are made; what meetings are held in order to make those decisions, and who is allowed to make the decisions and check on them. Few of these unbending prescriptions were forged deliberately and consciously.

"All of these are somehow bundled into the 'social architecture' or the 'organizational dimension: the seat of governance'," Shapiro says.

Or, as he put it even more graphically in a slide from a recent presentation to a conference in Barcelona entitled From Hardware to Wetware: Developing an Enterprise Architecture Framework Consistent with Enterprise Culture and Values: There is always a story attached to the question: "Why do you have this !!@#$% in your application portfolio or infrastructure".

"A lot of your IT has been driven by past decisions that people have made," Shapiro told CIO. "When you speak to people about their application portfolio there is always a story. You ask them why they have that application, and they say: 'Well, at the time . . . ' So you can almost go on an archaeological dig into the IT in the organization, going back and back and back to the decisions that were made and the politics that were in play at the time that the decision was made, and you see this reflected in the IT that's on the ground today. When you start digging you see the echo of the politics that were around at the time the decision was first made, which is important, because 70 to 80 percent of the IT budget goes on supporting those past decisions."

Page Break

Hammering the Changes

"If the only tool you have is a hammer, then everything looks like a nail" - as the old saying goes. If you do as most IT folks do, Shapiro suggests, and start developing your enterprise architecture (EA) model by evaluating the technology, such echoes of the past tend to become lost to you. You will only think in terms of technology. When you instead "look at the world from the opposite end, the people end", you can clearly see the effect the organizational culture has and how it echoes all the way through the organization. More importantly, he suggests this approach lets the architect focus on ways to plan the business response to ever-changing market, and environmental and competitive conditions.

The organizational culture can act like an organization's immune system, attacking any new ideas as if they were virulent bacteria and offering formidable resistance to change. "Organizations with a strong culture tend not to take on new ideas very easily," Shapiro says. "Culturally they are not programmed to take on new ideas. Culture surrounds and deeply influences the balance of the enterprise architecture." That is why challenging the information infrastructure and technology (IIT) in an organization is often theoretically easy and practically very difficult - because people keep getting in the way of rational behaviour. To prove the point, Shapiro points to Investec's experience after undergoing numerous mergers and acquisitions.

"The thing that you observe during those mergers is that the target firm often comes up with excuses for why things have to stay the same," Shapiro says. "They say: 'Well we can't change our IT because our business processes are so specialized; until the business processes are changed we can't change our IT'. And then the business process people say: 'Well we would love all to use the same business processes but we can't because we are confounded by the IT, so we can't change the business processes'. The interplay between the people and the IT and the organizations just fascinates me, so I came up with the title 'Hardware to Wetware'. It's about shifting your approach from 'hardware' (IT and related technologies) to 'wetware' (culture, decision making and the business model)."

Shapiro's experiences prove the point. Starting your IT analysis with the information technology architecture and expecting anything of value to emerge other than a bunch of self-satisfied engineers is a mistake, he says. Instead, CIOs and enterprise architects must start with the culture of the organization and work their way through organizational architecture, decision making, information architecture and business modelling until they finally get to information technology.

That is pretty much what he has done as CIO of the Investec Group. Investec is an international specialist banking group, with the network comprising five business divisions: Private Client Activities, Treasury and Specialized Finance, Investment Banking, Asset Management and Property Activities. It is listed on both the London and Johannesburg stock exchanges. Since its inception as a leasing company in Johannesburg in 1974 it has expanded through a combination of substantial organic growth and strategic acquisitions. Today it boasts an efficient integrated international business platform, offering all core activities in South Africa and the UK and select activities in Australia, with approximately 4400 employees in total.

"Investec IT is arranged with a balance of centralization and decentralization," Shapiro says. "In the main, infrastructure is centralized, while applications tend to be delivered by each business in order to allow them to pursue their own target markets. Strategic emphasis is placed on the tasks of architecture, integration and governance. Like most financial institutions we are busy responding to the ever-increasing regulatory pressure from Basel II and MiFID [Markets in Financial Instruments Directive]."

Formerly the group treasurer, Shapiro is now responsible for all aspects of IT in the group. He has held the industry elected position of chairman of the Bond Exchange of South Africa, and ran a consulting practice prior to joining Investec, where he has been for the past 15 years.

Page Break

Social Accounting

Shapiro's thought processes mirror the thinking on social force accounting of Rajesh Uttangi, who in 2004 prepared a white paper called Social Dimensions to Architecting Software Systems for Project Perfect. In his paper, Uttangi, a specialist with the Rational Competency focus group, Talent Transformation, Wipro Technologies, writes:

Alistair Cockburn in a paper titled On the Interaction of Social Issues and Software Architecture says "It has long been said, 'Architecture follows Organization' and 'Organization follows Architecture' . . . Architects do not like being told their clean design is a result of accounting for social forces. Project managers do not use their knowledge of social issues to influence architecture. Yet it is clear that social issues affect the software architecture in ways that the good architect takes into account."

Throughout the development cycle, architecture involves many aspects - business strategy, technical infrastructure, competitiveness, data and above all, delivering value to the stakeholders like the users, developers, managers and the architecture team itself. While the interests of the user community are well understood and religiously protected, the other stakeholders don't find so much support from the architecture. Because still they are expected to work for realizing the architecture and not use it as a tool to come up with a good system, bringing their own expertise to bear.

In complex systems, no one person covers the full breadth of technical expertise required to properly inform the architectural decisions, and lend credibility to the architecture, he notes. That suggests the need for a system definition that can represent the interests of different organizations. The architects on the team represent knowledge of the products of their organizational group (project, division and so on) as well as the relative priorities of their system requirements (organizational goals, and product functionality and qualities). Architects cannot exist and work in isolation from the rest of the organization.

But frequently the challenge for the architecture team is not to create an architecture that is "as if of one mind" - that is, having the quality of integrity - but to create one at all. Many times it is even difficult to be able to orchestrate the minimal conditions required to complete the job. The reasons for settling for such a substandard work product are the difficulties on the social front - being able to sell the "vision" to the team, acceptable distribution of roles and responsibilities, common levels of understanding about what is to be done, timely communication and separation of concerns, et cetera. The trickiest ones are common understanding and communication.

Philippe Kruchten says that "the practice of architecture is a long and rapid succession of sub-optimal decisions, mostly made in partial light". Architecture projects are, by their very nature, ventures into uncharted territory and especially fraught with competing ideas on which direction to take. Without obtaining a consensus and solid leadership, indecision is like[ly] to reign.

While there is hardly any need to highlight the technical issues associated with architecture, the social aspects that continue to have ever-increasing influence cannot be ignored, Uttangi asserts. There is no doubt that there are team members who feel used, left out or ill-treated in almost all projects, particularly when the question of their involvement in the system's architecture comes.

"The problems are exacerbated by ever-growing size of teams, integration of cultures and faster turnover rates, increasing complexity and cross-technology interoperability concerns. If issues of stakeholder involvement, assimilation of ideas, recognizing contributions and mutual support issues are systematically, yet informally addressed, results can be pleasantly surprising," Uttangi states in his conclusion.

Page Break

The Heart of Organization

At Investec, such thinking is more than just speculative. Enterprise architecture at Investec is viewed as a pyramid, with culture (or behaviour) at the bottom, where it informs the social architecture, which sits on top of it. This social architecture in turn plays a big role in influencing the information architecture, determined by information needed from both the external environment (what the competition is doing and so forth), and also from internal sources. In order to make decisions the "social architecture" needs information. Many of the decisions revolve about the business model in play in the organization and go to the heart of the purpose of the organization.

The information architecture then feeds into the business model, which influences the applications, which in turn influence the nature and volume of data. At the top, finally, is the technology. In Shapiro's eyes therefore, starting with the technology is to ignore everything but the tip of the iceberg.

Instead, it is vital to account for culture in developing the architecture. Culture distinguishes between "okay" behaviour and "not okay" behaviour amongst groups of people in the context of the society or organization, he says. This sets the foundation for all decision making. The enterprise is a "melting pot" of influences and negotiations, which eventually form distinct observable patterns. These repeated patterns and ways of making decisions are reflected in organizational structures and formal and informal reporting lines.

Recognizing how resistant organizations with strong cultures can be to change, Shapiro says enterprise architects should use every tool at their disposal to create a common view or vision before embarking on significant change or any new development. The starting point should be the development of a common "language" or "meta-model", ideally recorded in an electronic form that makes it amenable to rigorous, automated analysis.

After all, the purpose of the EA is to communicate in order to expose our "mental models", he says. "People frequently misunderstand each other because they can use the same words while meaning different things. Similarly, the same words can create different mental images in people's minds. Until you can explain those different models by using a common language, you will create only misunderstanding. And since every organization is unique, the framework used to describe the organization should be unique. Using object-domain models to document the discussions around this framework naturally exposes some of the unique organizational DNA.

"We concentrate on language a lot in the work that we do in Investec on enterprise architecture, because the language - the way in which we say things and the words that we use - actually becomes the framework itself," Shapiro says. "And we use an object domain model which derives from the object world of the 1990s, to document the discussions that we have about the framework.

"That term 'object domain model' has got analogies in other fields. In the heyday of artificial intelligence we would have called it the 'semantic database'. So now if you go and have workshops across the organization, the purpose is to flesh out the semantic model or framework: looking at the language that we use - especially for the relationships between objects - in the object domain model does exactly the same thing."

Shapiro says that although the framework to record business processes does little to reveal the organizational DNA, the bottom layers of the pyramid reveal much about its nature. For example at Investec the object domain model shows that a business area consists of people, and people belong to a business area. Those people have differing roles, but as a people-centric organization, there is no sense of role hierarchy in the organization. A hierarchically-centric organization would have a very different diagram.

"In our place it is a hotly contested area; you need to listen to the words that you use. For instance, take the fact that the business area consists of people who fill roles - we insist in the discussion that it is recorded like that: the business area consists of people, people just happen to have a bunch of roles. We are insistent on describing it that way because this is really part of the culture that we hold very, very dear. So when we look at an HR system, if it talks of building an organizational hierarchy of 'posts' and filling them with 'full-time equivalents', the language really jars."

Page Break

A Matter of Influence

Shapiro says it is important to recognize how cultural and social influences play into all of the decisions around infrastructure and technology.

"Of course this is especially true in organizations that are package-centric," he says. "In these organizations, once you have looked at the desired business processes then you go out and look at applications that meet those needs or deliver those business processes, and then you leave behind a trail of data.

"Often when you buy a package you can't predict the way in which the package itself arranges the database. In our place, which has grown from a lot of acquisitions, you can't even dictate the base technology that it is on: You need these business processes, you need these to get this product to market, therefore you need this application, you get by default this data, and in this or that format. So often what you have to do to serve the need of the organization is to take that data, integrate it, and somehow analyze it and turn it into information in the language of the organization," he says.

While the approach is paying dividends for Investec, Shapiro believes there is valid research to be done on ways to make the development of the meta-model (or language of the organization) more rigorous so that organizations can be compared on this level, and to determine whether there really is such a thing as "true organizational DNA".

In the meantime, he says CIOs should consider architecture as a set of tools they can use in a coherent manner to record the style of an organization and its culture, behaviour and organizational architecture. An enterprise architecture can be very powerful if its architects take a leaf out of the book of construction architects, he says.

"You know what architects do: they all do drawings. They often use the new 3D modelling tools to make sure that things work dynamically as well as statically, and they bring in cardboard models, they bring in samples, they do almost everything that they need to do to communicate an idea to their clients. That's what the architecture practice based in an organization should be doing.

"It is all about using whatever devices that you have at your disposal, hopefully captured in a coherent fashion, against that framework I spoke about earlier, but then you have to expose these so that discussions that need to can take place. The key feature of this approach that is different is that it's more encompassing. It recognizes the very important role that business process plays and the interplay between process and IT. So it gives a lot of prominence to the process part rather than the IT part," he says.

That is a lesson they have already learned at Investec. Shapiro says at one point the organization did a "zero base" project, which turned into a classic enterprise architecture project. All of the difficulties, he says, were there and observable: the lack of documentation, the amount of time that it took to re-establish the fundamentals of the architecture, the difficulties of documenting it in a coherent fashion, and the fact that you spend 95 percent of your time in data collection and only 5 percent doing analysis because it was not documented originally. In short, the project suffered from all of the usually complexities that come with an architecture project. What it did shine some light on was why the organization had, after years of acquisitions, ended up with six or seven CRM applications, three or four banking applications and numerous trading applications.

"You start asking the people why, and the stuff starts coming out and you always trace the most difficult roots back to the people and the attitudes that they have towards each other and why they need to hide behind their system. You can't rationalize jobs if the systems are different and all this soft politics lurks in that discussion," he says.

"It gets to the point where you just have to turn all that on its head and look at it from a different angle. And as you do that you realize how important culture and behaviour are in driving the IT agenda rather than the other way around.

"Otherwise, as you know, we all just follow the Zachman Framework [a formal and highly structured way of defining an enterprise's systems architecture] and spend our lives documenting the different layers of Zachman's diagram because he told us to."

His theme, Shapiro says, resonated in Barcelona, where numbers of people welcomed such non-classical thinking on the topic. Some might almost say it was a religious conversion.

Page Break

SIDEBAR: First Movers in IT Governance

The early bird gets more than the worm

By Vivek Mehra

First-mover organizations are those that are first to establish a significant presence in a given market or domain, and thus are able to use that as a basis for competitive advantage. First movers in IT governance are organizations that realize the importance of effective governance of IT assets (resources, software, hardware, services, products and the like) and exhibit traits that enable them to proactively address governance issues.

As IT becomes increasingly commoditized, all organizations have access to the same technologies and tools. What often sets some apart is how they apply these common technologies in support of business processes. Successful technology implementation, and the success of IT as an enabling organization, is determined by the innovation and effectiveness of IT governance in the enterprise. First-mover enterprises differentiate themselves by recognizing the importance and relevance of IT governance, and they seek to continuously evolve governance structures and process in lock-step with their business needs.

First movers are alike in their level of clarity with regard to three key areas of IT governance:

1. Organizational governance. Includes governance of internal roles, titles, hierarchies and human-resources-related functions.

2. Vendor or partner governance. Includes contract negotiations and maintenance, program coordination, monitoring of quality of service and related functions.

3. Enterprise architecture governance. Includes governance of business architecture - business processes, functions, organizational structure - and also governance of systems, data and infrastructure architecture.

All organizations shape and tailor each of the above governance aspects and determine decision-making authority based on the specific imperatives and drivers of their businesses. However, first movers have several distinctive qualities:

• Differentiated business drivers: First movers focus on which of their business drivers are dynamic and therefore need a quick response. For example, finance and banking companies often gain competitive advantage by continually adding new products and services; they also feel a lot of competitive, regulatory and technology pressures. Therefore, their governance or decision making has to be nimble and supported by structures and processes that facilitate rapid information flow. In addition, to ensure agility, decision making needs to be federalized and typically delegated to lower levels in the IT organization.

On the other hand, an organization that is in a relatively non-volatile or mature sector, such as government, transportation or food processing, has business drivers with slower rates of change. IT governance processes and structures in such an organization need to be more focused on internal operational efficiency and can afford to display a lower level of agility. Here, IT decision making typically is either centralized or is completely decentralized in localized business units.

In reality, enterprises have a mix of "fast" and "slow" drivers and have to align organizational and vendor governance structures and processes accordingly. Yet first movers alone recognize the importance of enterprise architecture governance and the need to match IT initiatives with business goals. First movers in IT governance have processes and structures that foster ongoing interaction and collaboration between business and IT domains, especially for the planning and execution of IT initiatives, thereby enabling good business and technology alignment.

• Leadership Influence: First movers also have a culture where their business councils and groups have established channels to influence the highest-level leadership. This provides feedback on decisions and their impact - thereby creating dynamic, self-correcting governance structures.

To find out what works and what doesn't, first movers typically monitor the nature and effectiveness of their governance mechanisms. They monitor accountability at multiple governance levels and track the business value or return on investment achieved from specific IT initiatives.

• Cultural Alignment: Another quality first movers have is that each of the three governance aspects discussed above (organizational, vendor and enterprise governance) are modelled to align with the cultural orientation of the enterprise as a whole. So, if the enterprise views its independent lines of business as truly autonomous entities, it will federate its decision-making capability if it is a first mover. If the enterprise values a collective approach where each line of business has the same processes and tools, to be a first mover, the enterprise will establish strong centralized governance functions.

With effective IT governance, organizations can reduce cost of ownership, increase operational efficiency, and keep pace with changing business needs. Organizations take the first step in becoming first movers by recognizing the importance and relevance of IT governance. First movers establish structures and processes that reflect their mix of fast and slow business imperatives, as well as the cultural orientation of the enterprise. They also emphasize collaboration between business and IT, and continually measure their governance effectiveness. In doing so, first movers ensure that the promise of IT as a business enabling organization is fulfilled.

Vivek Mehra is director and chief enterprise architect for Global Financial Services at Keane Incorporated