AIM part 9, AIM Data in Context

One of the most daunting challenges in any IT transformation is the ability to see how all of the pieces will eventually come together - both in terms of organizational or initiative coordination as well as in terms of the eventual solution architectures. One of the challenges that we face with AIM is that traditionally AIM data has risen through the data value chain (of related architectures moving from static to dynamic) rather slowly and often in an indirect fashion. All of this will change when the family of new initiatives arising from a new AIM foundation begins to emerge. In the relatively near future, all civil aviation data will become accessible to all civil aviation IT capabilities and all their related processes.

The diagram below illustrates the point - the tiers of the architecture (which is in fact a set of federated capabilities, systems, services and organizations) roll up into a Common Operating Picture from which all those who participate in the various civil aviation processes can access - according to their respective roles and privileges. This provides centralized access control mechanisms for increased security as well as opportunities for more comprehensive data integrity control - something that will become ever more important as civil aviation processes become more automated.



Civil aviation is compromised of various data domains, temporal domains and architecture tiers, AIM underpins them all...

Copyright 2008, Semantech Inc.

AIM part 8, The Data Chain of Custody

One of the primary concerns that needs to be taken in consideration when building a generic reference model for AIM is the data chain of custody. What this refers to is how data is managed across the various steps in its lifecycle, and in many cases those steps will hand data off from one group or organization to another. Knowing from the very beginning that this is going to happen; that this will effect the integrity & accuracy of the data which eventually will be used by pilots and traffic controllers requires us to mitigate the issue up front as much as possible.

There are several key 'zones of data control,' these zones represent the most likely points at which data will pass from one system or organization to another. What makes this even more complicated is the fact that in the near future, these zones of control may not be restricted to one civil aviation paradigm (such as the FAA's NAS or National Airspace System) - the zones will become interchangeable across ICAO member states. Some of the issues may be mitigated by adoption of the AIM canonical data (exchange) model - AIXM, but not all of them will.

The reference model must therefore taken into consideration the following factors:

• How and where to evaluate data integrity near the zone boundaries.
• How to ensure accurate transformations into and out of AIXM.
• How to assign service level metrics and responsibilities to the various participants in the overall data lifecycle.
• How to design for efficiency - to ensure that critical update data reaches end-user operational systems in near-real time.
• How to design "traceability paths" into the architecture.
• How to document transformations from inception to final evolution and to trace back the core authoritative elements (and to assess each transformation against validated rules).
  

Copyright 2008, Semantech Inc.

AIM part 7, Process Mapping

In situations where many architectures must be reconciled, the ability to map between them becomes extremely important. The actual development and deployment of modernized AIM solutions will involve quite a lot of such mapping, especially in regards to managing data exchange (i.e. the AIXM model).

As one might imagine though, data architecture is not the only place where complex mapping may need to occur in order for the Global AIM community to arrive upon a common reference model.

Process is especially important to the Global Civil Aviation community given the priority focus on safety. AIM processes involve not just those associated with managing the solution itself (from an IT perspective), it also encompasses the processes utilized to gather, aggregate and validate data and then those processes used to integrate AIM data into operational Air Traffic Management systems.



Copyright 2008, Semantech Inc.

AIM part 6, The True Scope of AIM

One of the major questions that has to be asked at the beginning of an endeavor such as this is "what's the scope?" We know how AIS is interpreted now, how it's realized across dozens of existing systems and publications, but AIM is intended to become quantitatively different. AIM as currently defined by most of the major players represents a major extension of the current AIS mission, with specific expectations regarding unified management of core data and universal data exchange. However there are still some separations in the envisioned "to be" architecture which require some consideration in regards to determining just what the scope AIM really should be.

The primary issue is the relationship between the new unified data architecture and operational management of the airspace - variously referred to as Air Traffic Management or Air Traffic Control. There are quite a few implications that come along with new capabilities such as the ones we're discussing. For example, access to near-real time data between systems on airspace modifications will make a huge difference in how airspace and flight management occurs in the future, however it also dramatically impacts current processes and potentially impacts security.

The problem we have here is by subdividing aspects of what we're talking about - CDM, SWIM, AIM we run the risk of losing sight of the synergistic issues and there will be many of them. Once responsibilities are parsed among the pieces of transformation, who will be then responsible for the whole, if we wait until the solution is completed to figure that out it will be entirely too late.

The diagram below begins to illustrate the point - the nature of the data itself is not easily separable any longer from the holistic views that will be required to manage civil aviation. When we design the new AIM can we design without understanding what that holistic picture needs to be and what the Air Traffic Management implications will be?



Copyright 2008, Semantech Inc.

AIM part 5, Coordinating Global AIM - The Process

Coordinating a global reference model is no simple task, there are many considerations that must be accounted for. There are existing architectures, varying interpretations of existing requirements, a large group of participants - each one including their own orbit of further participants and a variety of technical approaches already at play (both in terms of architecture description and applied solutions).

There are some areas though of great similarity. We have the starting point of the ICAO Annex 15 requirements as well as a fairly universal adoption of the Unified Modeling Language (UML) in some fashion across most of the participants. The best place to start perhaps is the capture of scenarios that are common across all of those involved with civil aviation in the form of Use Cases. The tools used to capture the Use Cases are not so important as the two elements of any Use Case is a textual description and a graphic diagram - there is no need to deploy a centrally managed CASE tool to capture these. We can view these as unstructured (data) architecture support / artifacts / products (depending on your terminology). They can be captured using wiki technology.

The diagram below represents an initial visualization of how these various factors will relate to one another:



Copyright 2008, Semantech Inc.

AIM part 4, The Global AIM Framework

There will be four core reference models as part of the AIM Global reference architecture - these should roughly correlate to other initiatives and at some point will provide specific mappings as we are updated on how the various programs are evolving. All four of these models are derived from core ICAO requirements but some of this extends beyond what has yet been identified in those standards.

The four reference models are:

1. The core Semantic Model
2. The Data Architecture Reference Model
3. The Services Architecture Reference Model
4. The Information Exchange Model (this is mostly already completed as part of the AIXM initiatives although there is some further correlation with the other architectures that might require attention)

Copyright 2008, Semantech Inc.

AIM part 3 - Principles of Integration

I've found it useful to start major architecture or enterprise transformation projects / initiatives with a statement of principles to guide all follow-on activities. This is especially important for any architecture-focused efforts as they often become easily sidetracked or overly introverted in nature. In the case of Global AIM, we are looking at a very diverse community of practitioners and developers who bring quite a few unique perspectives to the problem space. If we viewed a joint or global EA effort too strictly it would quickly become bogged down in complexity - our principles, listed in the diagram below should help to prevent that from occurring.



Copyright 2008, Semantech Inc.

AIM Case Study, part 2 - Current Global AIM Initiatives

Aeronautical Information Management (AIM) is not new, a number of significant efforts have been underway for since 2000 in order to help define it and reconcile it across the interests of many nations' civil aviation strategies. Eurocontrol has take a real leadership position thusfar by producing a Top Level Reference model and a data exchange model:

• AIXM - Aeronautical Information Exchange Model
  
• OATA - Overall ATM Target Architecture

The FAA has also been a key player is these developments and has helped to define these existing models and provide vision for future systems. The somewhat symbiotic relationship between The FAA and Eurocontrol is worth highlighting:

Copyright 2008, Semantech Inc.

Agile EA Case Study: Global AIM part 1

We'll start with the overview presentation:

| View | Upload your own

Top 10 Reasons SOA Projects Fail

Last month an interesting study about SOA implementation success rates was released:

The Burton Group SOA Study

It states that fully 50% of the projects assessed were considered a complete failure and 30% more seriously underperformed. That leaves only a 20% success rate - this track record is nothing less than dismal. Why is this still happening? Why is SOA so difficult to realize?

Well, rather than writing a dissertation, let's address the root causes with a top ten list:

1. There is still no widely agreed upon set of best practices for SOA implementation (or for that matter even an industry standard definition for what SOA is and isn't).
   
2. The confusion regarding SOA and web services is still pervasive; technically you can have SOA without any web services being developed per if the architectural principles are met.
   
3. SOA is not application-centric, despite appearances to the contrary. SOA is the first and only comprehensive development paradigm that is wholly integration-centric. (it combines the previous middle-ware integration capabilities with OO and web-centric logic).
   
4. Most SOA architects don't have a clue about 75% of what a true enterprise integration requires. Solution integrators tend to hire former J2EE / web services developers and assume that they will magically grasp the intricacies of System of Systems enterprises magically from the giant wisdom cloud in the middle of so many diagrams. NOT...
5. SOA without the enterprise data layer isn't going anywhere, fast.
6. COTs driven SOA is inherently risky, as the recent merger between two of the four leading vendors has proven (Oracle buying BEA). How many people are now having to reassess their infrastructure as a result?
7. Deploying a SOA stack in itself that doesn't actually do anything is an intellectual exercise to be sure, but also a complete waste of time and money.
8. SOA is dynamic, or at least it's supposed to be and more importantly it is not our first foray into managing dynamic environments, so why does the industry seem to have collective amnesia in this regard? Systems engineers have been doing what SOA developers are failing to do now for twenty years, yet you'll never see a member of that rare species on most SOA projects.
9. Developers rule - NOT. Design also drives development not the other way around, we wouldn't want the drywall guy designing a skyscraper, yet that happens in SOA implementations (figuratively speaking). Some people call this model-driven SOA, however it was the way SOA was always supposed to be conducted. You can't really do "Agile SOA" in the strictest sense of the Agile philosophy given SOA's integration implications - the big picture has to be understood up front.
10. The standards and hype don't drive the solutions, the business does - if we remember that we can avoid some obvious traps. Hype doesn't solve problems or deliver capability and the standards that are applied are the ones that make sense, not merely the ones everyone says ought to be applied in a perfect world.
    

copyright 2008, Semantech Inc.