Blueprint for Harmony

But when the dances ended and the business aristocrats began to emerge - stony broke and wincing at their naivety in having fallen for Vendor's seductive promises - EA was waiting, grubby but glowing with inner beauty, shyly offering herself as a promise of a new and better Kingdom to come. Her overtures have prompted many IT Knights of the Realm to take a renewed interest in this neglected child.

Now that the party season is over more CIOs are ready to listen to enterprise architecture's long-standing claims that the realisation of an effective information strategy requires the definition of a consistent architectural framework within which individual projects are conceived, justified, built and deployed. Partly that is because a volatile e-business environment finds organisations having drastically altered business models thrust upon them in the name of endurance. It is also because growing numbers of organisations are discovering how brittle are those environments where Internet-based front ends talk to back-end databases or CRM solutions, and are recognising architecture as a way of resolving those issues.

The problems facing organisations trying to convert themselves into e-businesses are helping CIOs to realise the value of a good architecture. They know that unless they plan for redundancy, scalability, application integration and rapid application modification up front they will be forced to do so later at vastly increased cost. As a result, CIOs are re-embracing the corporate standardised platforms and applications that compose enterprise architecture as a way to contain costs and ensure business alignment in the Internet age.

"These days, if you've got Web services you've got dotcom, you've got .Net and J2EEE. You need to have some sort of overall architecture blueprint to say where everything fits, the sort of areas you are going to focus on, and the sort of technologies you think appropriate for your business and your environment," says Carlo Bonato, manager planning strategies, Victorian Department of Human Services.

Bonato says the department had a very good architecture for the 1990s - built around its initial work in the early part of the decade in systems development - which had become established, then mature, then outdated. Now it is working to match the changed circumstances of the organisation to a refined EA. "We want to identify with the business the best way of achieving some of the results, so we will move forward on that basis: that there is a clear approach and a clear message we're giving both to the business units and to the rest of the organisation. The message is that this is the agreed way that we're going to develop systems; the agreed way we think they should be integrated; and we believe that will save us cost and effort and resources in the long term."

Whether enterprise architecture deserved its former bad rap, or whether the concept of a flexible architecture had to wait for the technology to catch up to it, companies struggling to regain control but retain enough vision to accommodate the "next big thing" are now looking to architecture to help. "For a few years there, enterprise architecture went quiet and where we saw an enterprise architecture being done was around large system development projects where there were multiple systems being developed at the same time," says Todd Heather, principal consulting director, DMR Consulting Asia Pacific. "Prior to that, enterprise architecture was really more often seen as an offshoot of IT strategy planning, so in the early 1990s we did a lot of IT strategy plans, and architecture was part of that.

Page Break

"In the last couple of years we've seen a real resurgence, and I think it's possible the resurgence was seen earlier in North America than here, but I think the consulting companies and the clients I work with are sort of starting it up again. Some of them are starting from scratch, some of them are starting from a good base, but are we that far behind North America? I would say not."

In fact it is not only US businesses that have rejected EA until recent times. The investigative arm of Congress recently reported half of the 116 government agencies it surveyed had not gone beyond the first of five steps needed to implement an enterprise architecture. While lauding Bush administration efforts to get US federal agencies to adopt enterprise architectures, the General Accounting Office lamented the failure, pointing to the administration's acceptance of the value of enterprise architecture in reining in overblown IT projects in testimony presented to the House Subcommittee on Technology and Procurement Policy.

"Most agencies are at risk of investing in IT solutions that will not overcome, but rather will perpetuate, longstanding incompatibilities and duplications with agency operation and systems environments," warned Randolph Hite, the GAO's director of information technology architecture and systems issues. Enterprise architecture consists of the strategy, design artefacts, technology and standards that guide the use and deployment of technology within an enterprise. This information set encompasses information both about the business and about the technology and systems that support the business. In essence, it is all about providing an organisation-wide context for decision-making.

"It's about making technology decisions and application decisions and information decisions from a business perspective in service of the whole enterprise as much as you can," Heather says. "So it's very much focused on centralisation, on shared services, on reusable objects and on good enterprisewide design, and having a plan to implement that design that's robust and achievable." In that sense the concept is hardly new. Indeed EA was conceived in the late 1970s, the offspring of IBM's widely-used Business Systems Planning methodology.

Over the years the emphasis has changed from using IT to help advance a manufacturing process or service to improving the way organisations tackle change, says Peter Bernus of Griffith University's School of Computing and Information Technology. "Then over the past 12 years, the understanding got a foothold that what organisations are really talking about is improving the way they tackle business chance, including using technology for the business purpose. And more and more interest was placed - apart from the technology - on the human side, and also on the business side. Where we are today is that we are trying to unify whatever management and engineering has to say about the continuous change in the enterprise."

Bernus says the term "enterprise architecture" is a signal that organisations are no longer talking just about integrating the enterprise using technology, but are rather seeking contributions from various disciplines including management, information technology, manufacturing technology, industrial engineering and numbers of others. Just as no one in their right minds would try to build a building without architecture, the name enterprise architecture is a signal that organisations can no longer talk about enterprise integration using technology without using architecture to define the enterprise, Bernus says. And Australia has been at the forefront of the moves over the past 10 years to look "pretty broadly at what is available in the world" to help organisations understand how "to architect" their enterprise.

Page Break

Leading the charge has been John Zachman, author of the Framework for Information Systems Architecture, now broadly accepted around the world as an integrative framework of information systems architectures.

Years ago Zachman discovered that industries that produce complex engineering products tend to achieve high levels of product sophistication, produce very complex products relevant to their markets, maintain very long product lifecycles, and accommodate substantial change over the life of the product. The findings led him to the conclusion that the key to establishing high levels of product sophistication and to maintaining their relevance in a dynamic marketplace lay in the structure of the design artefacts (descriptive representations) being produced over the process of producing the products.

Applying this same logical structure of design artefacts to enterprises resulted in articulation of the framework. Not only does the framework define a set of models relevant for describing a complex enterprise and building its systems, it also provides the logic structure for explaining virtually any technology issue or frustration.

Since then other processes have hit the marketplace, including that of Steve Spiedel and those from non-proprietary industry sources like The Open Group Architectural Framework (TOGAF).

Many organisations spend a lot of effort developing IT strategies, says Michael Tan, enterprise architect, Information Services Group, NSW Department of Transport and Regional Services. But IT strategy alone does not give you the details needed for implementation. IT strategies represent, in essence, the things an organisation needs to do. In most cases, they are projects, and IT strategies may not contain the technical depth required to implement the projects.

"Business environments are forever changing," Tan says. "So is the IT landscape. Finding a product or a model that best meets your business requirements is anything but straightforward. In data modelling terminology, it is a many-to-many relationship. Any business requirement can be met with a multitude of products or combination of products in the marketplace. Worse still, many of the products also carry with them inherent directions as the products evolve. You may be locked out of future options." Enterprise architectures provide a discipline for resolving the match, Tan says.

"Consider the typical case of implementing e-business solutions. An organisation may have decided to go e-business. But, how do you do it? There are as many answers as there are products in the marketplace. Selecting and implementing a product is only one aspect of the equation. What about all the legacy systems you also need to integrate?

"While system architecture focuses on the nuts and bolts of a particular system, enterprise architectures are concerned with the building blocks that can be used across all systems. It is not just about a system. It is about how all the systems can work together consistently and efficiently, realising your strategies."

In data modelling terms, Tan says, the information and application architectures are really the intersection of business and technology architectures.

Tan has developed an enterprise architecture for the NSW Department of Transport and Regional Services and is now implementing a strategy based on filling the information gaps within applications. He says the process has helped the department discover the issues and shortfalls surrounding existing applications even while helping the organisation decide what the new architecture should look like to address all those issues.

Page Break

"The end product of your architectures is about how you go about providing the information at the least cost," Tan says. "And it goes down to your technology. You have to manage your technology diversity. You must make sure that your technology is sufficient, and also up to date, and that it is actually flexible so when there is a better technology on the horizon you can switch across."

Experts say the benefits of having an EA are potentially manifold. According to Bernus, when it comes to the day-to-day running of the business, using enterprise architecture to improve the way the organisation does business and uses its technology and people creates many efficiency dividends. Equally important are the wider benefits, including providing the organisation with an enhanced ability to respond rapidly to change. "It allows the enterprise to develop a survival capability and flexibility and dynamism, which otherwise is very hard to achieve," Bernus says.

And it vastly improves the organisation's chances of achieving true business/IT alignment. "Successful deployment and use of enterprise architecture will provide an environment in which IT solutions can be more closely aligned with business requirements," says Chris Nugent, senior vice president of worldwide sales and marketing, Popkin Software. "With rapid pace of change and the competitive pressures in the commercial world, business-IT alignment is typically the number one problem facing IT today."

Nugent says the benefits of a well-deployed enterprise architecture include: Quality IT systems built in line with the requirements of the business with less deviation, greater interoperability and greater adherence to standards. Investment protection the IT infrastructure and applications represent enormous investments in time and money. They should be built to last and easy to maintain. Lowered costs enterprise-wide standards open the way for streamlined operations, volume purchase agreements and significantly reduced support costs. Faster time-to-market - greater reuse of processes, knowledge and designs leads to faster implementation using proven techniques.

Nugent says synchronising business requirements, strategy, infrastructure and processes with IT infrastructure, data, systems and processes within an enterprise architecture can achieve business-IT alignment. But he notes a successful EA requires a strong buy-in and support at all levels, from the executive to the development team, not to mention a high degree of governance and effective knowledge management. And he warns deployment of an EA is a typically a significant challenge for an organisation.

"Strategies for enterprise architecture can be reduced to purely academic exercises if there is no effective mechanism for deployment of the standards, monitoring their effectiveness and maintaining them in line with an ever-changing knowledge base," Nugent says.

Australian Defence Force (ADF) is completely overhauling its information environment following the endorsement of a centralised enterprise architecture framework as recommended by the Australian National Audit Office (ANAO).

The office is working to a three-year plan to embed an architectures approach to improve the design and management of the Defence Information Environment (DIE). The task to embed an architectural approach into the design of the DIE is being pursued under the following guidance: Architecture must not be imposed as new work onto old practices.

Only architect for a purpose: just enough just in time, concentrating on problem areas.

Page Break

Lieutenant Colonel John Ramsay, director Defence Information Environment Architectures Office (DIEAO) says the real value to Defence is that it provides a mechanism for understanding and managing complexity in the organisation. "That's the simplest way of understanding what an architecture does for us. It's giving us visibility of interoperability requirements we have between Defence systems, in particular systems that are still under development," Ramsay says.

"It's giving us a mechanism to get visibility of activities that impact on the Defence Information Environment, in advance of them happening. It also shows us where we have gaps or duplications in Defence capability. And the important one as far as the Audit Office was concerned was that it gave us that audit trail that we could then use to justify either proposed or existing systems investment, because that demonstrated to us what the linkage was between the investment and the Defence outcome."

Unfortunately, however seductive enterprise architectures might appear, not every organisation has the ability to architect and continuously evolve the enterprise, says Bernus, and developing that capability requires a significant investment. In addition, organisations are likely to meet as many cultural barriers as technical ones.

"If you or I are working in an organisation like a large bank or a large utility," says Heather, "and we're trying to prove some enterprisewide plan to make decisions, create an IT environment that supports everybody with shared components, we're going to run into some opposition.

"The opposition will stem from some people who have an immediate need, who want to see a problem fixed now or a product that they've got to get out into their marketplace quickly. Their argument will be: 'I can't wait for architecture, I've got to get going.' So architecture is about having a long-term focus, and having that long-term focus on the organisation will often bring you into conflict with people that see themselves as having a short-term need."

Heather says the message from Zachman, who spoke at a conference in Australia recently, is that short-sighted thinking in the long run will cost you more than taking a longer view. The other difficulty that is likely to arise, he says, is where IT is seen as separate from the rest of the organisation. "If the enterprise architecture is seen as something IT is doing, sometimes the business will regard that with suspicion. Ideally you want to package your enterprise architecture work as building a bridge to the business," Heather says.

"People hire us to come in and do an enterprise architecture because they've got a problem with say, their Internet architecture. The real benefit they get out of the process is that a dialogue is opened up with the business about where the business wants to go and how IT can get in and support that behind them. So that's an issue - the IT-business dialogue that emerges when you do enterprise architecture - but you can actually solve [it] with enterprise architecture work," Heather says.

According to Ramsay, it is also important to educate people about the importance and value of EA as early as possible in the process, so they do not merely see it as a barrier to achieving their goals. "The other lesson is get your governance mechanism established as early as possible, because what you're doing there is sending out a whole new herd of cats and you really want those cats in line as quickly as possible. You must have that governance in place very early.

Page Break

"We also tried to find the simplest tools available to do the job. That has been a difficult thing: there are so many people out there claiming to have enterprise architecture tools, but those tools are themselves extremely complex."

To get around the problem Defence is issuing high-end powerful architecture tools to the small group of people who need them. For the rest, the majority who simply need an architectural process, relatively simple tools like Word, Excel or PowerPoint are likely to be all that is required.

"It's only when you want to get visibility across the enterprise that you need to invest heavily in high-end tools," Ramsay says. vThe Four Pillars of EA WisdomMichael Tan, enterprise architect, Information Services Group, NSW Department of Transport and Regional Services, defines enterprise architecture as consisting of the following four architectures, the pillars of your IT assets.

Business architecture. By business architecture, Tan means the high-level processes of the business. An enterprise architect needs to know the key processes of the business in order to gain understanding of the business issues. This is important because IT exists to help resolve business issues and enhance business standing. Without an understanding of the business issues at hand, technology per se has no meaning, he says.

Information architecture. Information architecture is concerned with how data should be collected, stored and transformed into valuable information. There are many issues relating to information: ownership, sharing, storage, culling, transformation and privacy issues and so on. The key objective here is to develop business advantages using information transformed from the raw data collected. CRM relies heavily on your data holding.

Application architecture. Usually represented by interconnecting block diagrams denoting systems, application architecture is about how systems interoperate to support key business functions. In recent years, enterprise application integration (EAI) dominates this area. Many vendors claim to be able to integrate your systems whether contemporary or legacy.

Technology architecture. Technology architecture shows how a system can be constructed with current technologies. This is the nuts and bolts and the building blocks that make up your systems. This area is full of acronyms from the marketplace: J2EE, .Net, CORBA - just to name a few. But this is a critical area, Tan says. "This is the minefield. Trek with care," he says. "You need to separate the marketing hypes from reality. How do you do that? You need your enterprise architect to run R&D-type projects to ascertain firstly if a product does what it says and equally important, it fits in with the rest of your building blocks."

Page Break

In EA's Defence

The Defence Information Environment Architectures Office (DIEAO), established in February 2000, is working to a three-year plan to embed an architectures approach to improve the design and management of the Defence Information Environment (DIE).

YEAR ONE: 2000 - DESIGN

Investigation and design of an appropriate Defence Enterprise Architecture Framework (DAF) and supporting processes for the Australian Defence Organisation.

YEAR TWO: 2001 - COMMENCE BUILDING

Establish practitioner training and management education in the DAF and processes. Commence population of the enterprise architecture. Investigate the availability of suitable architecture tools and selectively build prototypes.

YEAR THREE: 2002 - CONTINUE BUILDING AND REVIEW

• Ongoing population of the enterprise architecture and tool selection.
• Develop architecture evaluation criteria.
• Conduct evaluation.
• Adjustment to DAF and processes.