IT Role Players

Today I had a conversation with someone about the difference between an analyst and an architect. This blog entry comes out of this discussion where I share my opinion about various Information Technology (IT) roles.

• Analyst - Someone who spends time analyzing, decomposing the subject matter and sometimes provides the best option depending on the requirements. This person is not involved in coming up with a noveau solution but rather is involved in doing detailed analysis. There are requirements analysts, business analysts, process analysts, chain-management analysts, financial analysts, technical analysts, security analysts, program analysts, etc. etc.
• Architect - This role is a confusing one. I have heard that it is every developer's goal to be an architect or this person is nothing more than a technically savvy project manager. I have also heard that an architect is nothing more than a glorified analyst. After doing Architecture for eighteen months, I have to say it is a hard job. (Don't get me wrong. Analysts also have a hard job since they have to extract their analysis from information which is explicit and implicit). Architects take the analysis from the analysts and synthesize a solution for the problem. The architects have to consider the tactical constraints and its alignment with strategic goals. This person has to constantly ask himself, "Does my proposed architecture satisfy the customer needs, align with the strategic roadmap, meet the project deadlines and can it be implementable with the current resources (i.e. resources, infrastructure, standards)." There are enterprise architects, application architects, software architects, solutions architects, infrastructure architects, services architects, data architects
  
• Standards Person - This person usually work in a Technical or Functional Group defining standards for a particular domain. He or she needs to have good analysis skills, architecture skills and most importantly have excellent written and oral communication skills. This person needs to level expectations with the organizations they represent in the Standards groups and at the same try to push their organizations requirements into the standards specifications. They have a hard job of strategically aligning the standards, (they are working on) and their working bodies goals and with the organization's goals. Word smithing skills should help. There are standards people are involved in technical standards, and process standards like Software Development Lifecycle (SDLC) and Configuration and Change Management processes.
• Engineer - This person is a problem solver and he is usually involved in the "weeds". Usually the architecture aligns strategically with the organization's goals, meets all high level requirements and meets all other constraints. However this person addresses the finer problems within the overall architecture and solutions that maybe temporary fixes or configuration changes. For example there exists a mission critical system which was architected perfectly however the user base has increased eighty five percent and currently the system is experiencing a significant lag time which is affecting a business process. The next release is in six months. This is where the Engineer steps in. He determines the problem, designs a solutions and implements it. He documents the problem, design and implementation for the architects in the next release. Voila! The engineer has saved the day again. There are software engineers, systems engineers, process engineers, test engineers, etc, etc.,
  
• Developer - This person takes the high level architecture, designs the low level design and then implements it. If the architecture doesn't address the details because the architect doesn't have the time to design low level specifications or if the architect is not familiar with the technology then he or she can leave it to the developer. There are usually software developers.
• Programmer - If the architecture is extremely detailed and granular then the programmer has to implement the design. This is done where systems are designed to interfaces.
• Administrator - This person usually administrates an IT function. A system administrator administrates the system by maintaining and optimizing it within the constraints defined by the architect and the engineers. There are system administrators, project administrators, program and organizaton adminstrators.
  
• Project Manager - This person is responsible for managing and delivering a project which has beginning and end states defined. This person has resources to manage and is responsible for the appropriate deliverables to be completed within the project timeline. This person is not strategic but his or her main objective is to meet the end state with the project constraints.
• Program Manager - This person is responsible for managing a program which inconsists of on-going projects, projects to be executed and projects that were completed. This person is strategic since he or she need to program goals however they meet their strategic goals via projects which are tactical in nature. These people are comfortable dealing with project managers and their projects.

Please let me know what you think. These are my thoughts and I haven't spent any time validating if my definitions meet PMBOK or PMI standards.

AIXM is promising...

For the last few months, I have been indirectly involved in reviewing and doing analysis on the Aeronautical Information Exchange Model (AIXM) XML standard. After doing some initial review and attending the AIXM User Conference 2008, I believe this XML standard has a lot of promise. Here are couple of reasons:

1. Built on a mature and stable standard - AIXM is built on the Geography Markup Language (GML) which is a well accepted Geospatial standard. I believe this is a smart move from AIXM's perspective. AIXM can be used by all GML compliant applications with minor tweaking. When I asked the AIXM folks on why certain elements are modeled a certain way, their answer was that they tried to follow the GML standard. I believe this is a valid answer since they are merely extending the GML standard.


2. Domain specific - Unlike the National Information Exchange Model (NIEM) which has multiple domains, AIXM only addresses the aeronautical domain. Once again this is smart from a governance perspective since their Communities of Interest (COI) are limited. Even though NIEM allows various groups take ownership of each domain, NIEM is facing a problem with harmonization of data entities within the NIEM domain.

Things I would like to see from the next AIXM version:

1. Polish, Polish and Polish - Since AIXM is a international standard, I would like to see the standard XML schemas to be polished which includes:
   • adding annotations to each datatype and element
   • remove embedded elements within datatypes and elements and expose each datatype and element. This will make the standard more flexible and loosely coupled.
   • each element is uniquely named, this is quite common in the AIXM standard now since there are embedded elements in the datatypes


2. Publish XSL files - If AIXM published XSL transformation files, then it will be possible for applications to easily migrate to new versions of AIXM. I know this will take alot of work but I believe it is worth it.


3. Extract Geospatial data from Aeronautical data - I know that AIXM is an extension of GML however geospatial data is very bulky and can cause bottlenecks in a system. I would like to see pilots where non-geospatial data in AIXM format are serviced through a XML based service. Each element in the non-geospatial message can be mapped to geo-spatial AIXM element or message.

I think AIXM can be used as cutting edge standard. Since AIXM has just introduced the concept of time or temporality in its standard, I believe this offers the biggest promise. With temporality, I envision AIXM capturing some of the aeronautical business processes and eventually aviation systems will be using AIXM instead of BPEL and BPM. The problem with BPEL and BPM is that it is too generic and sometimes it cannot be modeled well for a specific domain like aviation. I might be dreaming but entities like AIXM should consider this option after all a BPEL file is nothing more than an XML file.

XML Based Framework Standards

After working with US government sponsored XML frameworks and standards for 2 years, here are some of my thoughts.

1. After studying Global Justice XML Data Model (GJXDM) and authoring all the datatypes in InfrastructureProtection domain in National Information Exchange Model (NIEM) version 1.0, I have concluded that these standard will never be fully implemented in Gov. to Gov (G2G) systems or Bus. to Gov. (B2G) systems. They are extremely bulky and may be potential bottlenecks in any system. Working with them can be extremely timeconsuming and sometimes redundant. The governance for these frameworks has not been fully resolved.


2. I, however, strongly believe these frameworks and standards are a key for any enterprise's efforts in addressing their data management efforts. The GJXDM and NIEM are one of the best data models I have ever worked with. They are well designed and are extremely granular. Eventhough they cannot be implemented by any system, they should be used a Rosetta Stone to evaluate any enterprise's data architecture. These data models should be referred when SOA governance and data managements issues are addressed.


3. Use these frameworks to reverse engineer various domain models. The GJXDM and NIEM data models are extremely rich. A great place to get requirements.

In conclusion these frameworks aka standards aka data models cannot be used as they were envisioned to be used, these data models are extremely useful when designing an enterprise wide data management system,