Aircraft IT MRO – Summer 2011

Subscribe
Aircraft IT MRO – Summer 2011 Cover

Articles

Name Author
Case Study: Power Play and the consequences of equipment upgrades and overhauls Karl Jones, Head of Avionics and Technology Development, Marshall Aerospace Ltd View article
White Paper: A Discussion on Project Management Wes Parfitt, CEO and Founder, EnvelopeAPM Inc. View article
White Paper: An Inconvenient Truth: CMS.. Thanos Kaponeridis, President and CEO, AeroSoft Systems View article
White Paper: Life is Dynamic: Business must operate dynamically too Michael Wm. Denis, Principal, ICF SH&E View article
Case Study: Challenges in capturing man-hours and materials consumed in airframe checks Dr. Roberto M. Asuncion, VP-IT, Lufthansa Technik Philippines View article

White Paper: Life is Dynamic: Business must operate dynamically too

Author: Michael Wm. Denis, Principal, ICF SH&E

Subscribe

Life is dynamic: business must operate dynamically too


The Value of Enterprise Architecture & Strategic IT Planning to MRO Business Transformation, argues Michael Wm. Denis, Principal at ICF SH&E, is that it is able to adapt to change while continuing to function

Numerous surveys over the past decade have reported upwards of 70% of IT initiatives across the MRO functional landscape as failing outright, failing to deliver business value and return on investment or running over time and over budget. This staggering statistic is a core reason why many airlines, third party MROs and aerospace companies have chosen to stick to their decades old custom coded legacy systems.

While the quality of commercial off-the-shelf maintenance, supply chain and document / content management solutions has advanced considerably in terms of functionality and technical platforms, the ability to plan, schedule, test, implement and train for new technology based capabilities is, to this day, a daunting task. Enterprise Architecture (EA) is a framework that provides structure and simplification to IT planning and capability maturity focused on enabling business processes, goals and transformation.

Who should own Enterprise Architecture?

Before delving into the detail of ‘what’ EA is, the most vital decision for corporate success is ‘who’ should own this discipline and responsibility. At a recent Gartner conference on IT Planning and Enterprise Architecture, Vice President for IT Strategy and Research, Philip Allega stated, “By 2016, 30% of EA efforts will be supported as a collaboration between business and IT (up from 9% in early 2011).”

While the trend in who runs and owns EA is definitely headed in the right direction, the current situation shows the IT origins of EA and the fact that most business units still rely on the IT department to define and enable their business strategy and operations success or failure. The aviation, aerospace and defense industries are at the higher end of the trend of having business process improvement reside in the business versus IT organization. One example is Delta TechOps, the maintenance division of Delta Air Lines. Delta TechOps has had a Managing Director, Process & Technology for over two decades. To some extent, this was a natural consequence of the airline spinning off their IT Department into a separate joint venture company in the early, 1990s. But the result was the formation of a group of industrial engineers taking over all LEAN, Six Sigma, Theory of Constraints, Business Process Reengineering / Business Process Management and information technology program responsibility for the company.

Dr. Pallab Saha, professor at the National University of Singapore, Institute of System Sciences (and self-proclaimed EA Evangelist), has a running debate on the Enterprise Architecture Network group of Linkedin on why EA should not reside in the IT Department. His top six reasons are:

6. Notwithstanding history and evolution, EA does not equal IT Architecture.
5. True EA leads to redistribution of authority and reallocation of accountability, both beyond the CIO’s jurisdiction.
4. EA value proposition and benefits are solely business realizable.
3. The primary goal of EA is to build coherent enterprises, not better IT systems.
2. Organizations are complex adaptive systems, hence holistic synthesis takes precedence over fractional analysis.
1. EA failure is a business organizational failure, not an IT failure. Resistance to EA is a consequence of failure, not the cause of it

Whereas many organizations do not have engineers, so the skills required of EA are not resident within business units, aviation maintenance and aerospace companies do; thus the natural fit for EA to reside within the business and not IT. The proper allocation of roles, responsibilities and authority for the various domains of EA are shown in figure 1.

Figure 1

What is Enterprise Architecture?

EA is actually multiple architectures and defined as the art and science of designing ‘something’ for a specific purpose. Most people identify architecture with the design of a building, landscape or urban area. In the traditional IT sense, architecture is used in the design of systems. In operations research, systems theory and the architecture of systems is a discipline unto itself and common within the military and aerospace industries.

The word prior to architecture is the ‘context’ or ‘focus’ of a design, thus Business Architecture, Data Architecture, Infrastructure Architecture, Technical Architecture and Solutions or Application Architecture are all elements of architecting or designing an enterprise. An enterprise can be an entire corporation or a significantly unique or independent business unit, in this case the sustainment lifecycle management of aircraft. Figure 2 shows the relationship of the elements and sub-domains of EA.

Figure 2

As the diagram above shows, EA starts with BA, which includes Business or Corporate Governance, Business Strategy, Business Capability Maturation, Business Process Management and Reengineering (BPR/BPM), Business Requirements specification, Organizational Design, Human Capital development, and Business Performance Management. Capabilities are, by definitions, the combination of people, organization, process, infrastructure, tools and technology that enable a business to source, transform and deliver products and services to customers and end consumers. Therefore, maturing or improving capabilities are solely the responsibility and domain of the business.

The context of EA starting with BA and the definition of success being measured by business performance is why Gartner research analyst Julie Short predicts, “By 2014, enterprises will make no distinction between IT governance and corporate governance.”

How does EA add value to maintenance and engineering organizations?

Building architects get to design their structures on a clean sheet of paper, when nothing exists: in a corporation, on the other hand, the formalization of the architecture has to take place while the enterprise continues to function and change. Every enterprise starts with huge amounts of legacy ‘stuff’ including hardware, applications and processes, much of it unwieldy and requiring constant maintenance. Creating competitive strategic advantage, business bonding to customers and implementing a new IT landscape that best enables the business while keeping operations running, is a massive challenge. As Gary O’Neil, Senior Research Engineer at the Georgia Tech Research Institute once said, “Transforming Air Force Materiel Command is like rebuilding an F-16 into an F-22, while in flight.”

The role of IT is changing. From automation and transactional support, IT has grown to be an indispensable part of operations. As technology transforms the way that organizations do business, the IT function plays a vital role in articulating the business strategy and objectives of enterprises. There are five basic rules to leveraging EA to add business value.

Rule 1: Know where you are now.

You can’t get where you want to go if you don’t know where you are. This is the single most important rule of EA. Many enterprises attempt to transform their business and IT landscape without a clear understanding of their current processes, systems and capability maturity. They rely on ‘tribal knowledge’ and approximate descriptions based on out-of-date information in multiple PowerPoint presentations, Visio diagrams, Excel spreadsheets and Word documents, often scattered across different locations. This inaccurate picture of the current process and technology map will undermine every planning effort.

In a recent study, Nucleus Research found that 42% of companies surveyed had made unnecessary software or hardware purchases that could have been avoided if they had access to more accurate IT asset data. When it comes to IT planning, the quality of your decision making can only be as good as the quality of your data, information, knowledge and wisdom (DIKW). Dr. Karsten Schweichhart, Vice President of Corporate Enterprise Architecture at Deutsche Telekom, puts it simply: “We cannot develop a sustainable target architecture if we don’t know where we are.”

Rule 2: Articulate the business strategy and goals to know where you are going.

There is a famous story about an FAA liaison manager at Southwest Airlines, back in the early 1990s. The FAA issued a Notice of Proposed Rule Making (NPRM) to have airlines conduct a seatbelt check prior to closing the cabin door and pushing back the aircraft. According to folklore, this middle manager called his VP and was in CEO Herb Kelleher’s office the same day constructing a response to defeat this NPRM. Why would a middle manager become alarmed by such a benign rule and why would the CEO get personally involved? Because the core business strategy was well articulated and communicated and this ‘middle manager’ understood his contribution to the execution of that strategy.

The corporate strategy was enabled by simple standardized capabilities (common fleet, lean processes), low cost point-to-point operations and maximum asset utilization all of which included a goal of 20 minute aircraft turns. The additional time to conduct a seatbelt check contributed to preventing one enabler of the corporation’s competitive advantage and success.

A clear picture of corporate goals and the contribution of people executing processes makes all the difference to the effectiveness and efficiency of an organization. This is closing the strategy to execution gap and aligning IT to business operations.

A clear picture of the business goal also makes a difference when creating the IT vision. IT is not an end unto itself but a business enabler. So it is essential to understand the business strategy first – including the goals and capabilities required to deliver them and then tie that to the lifecycle management of data, applications, infrastructure and enabling middleware such as enterprise service bus technology. “Enterprise strategy is what we focus on,” explains Gabriel Morgan, Principal Enterprise Architect at MSIT, Microsoft’s internal IT group. “When we integrate with enterprise strategy, IT strategy is really a by-product. The point is being a market leader in our product line: IT is simply an enabler to get there.”

Rule 3: ‘All do some’ not ‘some do all’.

The only way to get an accurate, real time view of the current IT landscape is to ensure that all changes are carefully tracked and that the information is stored in one place, system or tool. This cannot be done by one person alone or even by a dedicated team. It requires everyone who alters processes or technology to document changes, when they are made, to a central source.

Involving everyone responsible, rather than relying on a small group of experts who monitor changes is critical. It is the difference between the supply department taking inventory once a month and an airline that performs ‘point of maintenance inventory management’ using real time remove and install configuration control transactions. For a small airline, a monthly snapshot may be sufficient. But a major that operates extremely tight supply chains needs an up-to-the-minute picture of its stock to keep the business flying.

The same is true of enterprises and their complex process and technology landscapes – a real time view is essential to make good decisions. Yet, in a recent study, Nucleus Research found that enterprise IT decision makers rely on information that is, on average, 14 months old. To be honest, there are airlines that rely on EA artifacts that are 14 years old.

No software solution can provide accurate IT asset data on its own. It requires the right processes and the engagement of everyone responsible for business and IT change. Susan Green, Global Head of Business Enterprise Architecture at Bank of America, puts it like this: “It’s vital to know what we have, if we want to manage our business and technology from application portfolio management through to strategy definition and capability alignment.”

Rule 4: Collaborate and communicate to enable Enterprise Decision Making.

Many ancient civilizations have a ‘Tower of Babel’ myth, in which the world is thrown into confusion by the sudden appearance of different languages. It is impossible to collaborate if you can’t communicate and if there are no agreed words to describe objects and ideas, communication is impossible. One of the critical roles of EA, is to define and translate business and technology entities and artifacts to ensure that these definitions are used as a common language and are shared by all business units, technology vendors and the IT department. Only when a common lexicon exists is it possible to create an accurate model of the IT landscape and how these entities map to capabilities.

Accurate and consistent terminology is vital, but it is not sufficient. Terminology needs to be ‘rich’, which means it can address both business and IT realities. The manner in which you describe your landscape determines what you can do – e.g. it is only possible to manage vendor contracts if all necessary contract and license information is captured.

Ideally, IT planning forms part of business strategy development, informing executives of opportunities, risks and solutions, and suggesting clear roadmaps that maximize value and minimize disruption to operations. It’s vital to know what we have, if we want to manage our business and technology from application portfolio management through to strategy definition and capability alignment.

“We get a chance to bring IT to a very interesting peer level conversation with the presidents of the company,” explains Gabriel Morgan, Principal Enterprise Architect at MSIT, Microsoft’s internal IT group. “When the strategy is formed, the enterprise architecture captures that strategy, analyses impact and brings back the information to inform decisions on what can and cannot be done, and what are the risks. Based on that information, the strategy is then articulated. IT is a part of that decision.” This level of integration between IT architecture and business architecture is not common within the aviation industries. But it should be.

Rule 5: Use Enterprise Tools to transform Enterprise Capabilities

It is also critically important to both realize and embrace change. When planning a route, it is not enough to know where you are and where you want to be – you have to understand the flight path and environment in between. As Neil Stronach, Senior Vice President, Operations at Delta Air Lines always says, “IROPS [Irregular Operations] are regular and normal somewhere in the network every day.” Weather, aircraft on ground, crew disruptions, air traffic delays… events totally out of the control of the airline can change the best scheduled journey. The benefit of a navigation system over a flat map is that a map is static, hence outdated and incorrect as soon as it’s printed. A navigation system is dynamic, responding in real time to changes in the air and on the ground.

The same principles apply to IT transformation. Every IT roadmap is based on a host of assumptions that can change during execution. A vendor may discontinue one of its technologies; a merger or acquisition may transform the business; new external regulations may be enforced; geopolitical instability could spike the cost of fuel. If you are always ready to react to these changes quickly with real time knowledge, they will be much less of a challenge. Transforming the IT organization is like being in command of a cruise ship – it needs a lot of notice to change direction. If you can see the iceberg – it’s already too late!

In order to benefit from dynamic navigation, it is vital that you keep all your information and plans together in one enterprise class system, the map of your current location and situation, the vision of your future landscape, the radar of the environment in-between and the flight plan for getting from one pace to the other.

Microsoft Powerpoint, Excel, Visio and Word are not enterprise collaboration tools, even with the addition of Outlook and SharePoint. Even Microsoft Corporation uses specialized EA technology. Enterprise Architecture tools are the only way to ensure that the impact of any environmental change is fully understood in advance and that your navigation system is constantly updated to support corporate decision making in a way that will best achieve business goals.

Conclusions

Enterprise Architecture (EA) is a framework and human capital skill set that provides structure to capability maturity; simplifying, de-risking and improving the success probability of technology implementation and business transformation.

EA must be led by business leaders supported by IT experts. Many doing a little is preferable to a few doing a lot and ensures accurate information. Documenting the lifecycles of organizational structures, roles, workflows, processes, applications, data and infrastructure is critical to optimal decision making.

Finally, the use of specialized EA tools offers a high return on investment and is critical to business success. At the end of the day, MS Office and Post-it™ notes are no way to transform an airline.

Comments (0)

There are currently no comments about this article.

To post a comment, please login or subscribe.