MEGA - 'EA Standard' Product Review

Undoubtedly MEGA is one of the best Enterprise Architecture Modeling tool available in the market, but it does have its limitations, which I would like to discuss here. You want to make sure what you want and based on that you should procure relevant bundle of services from MEGA, rather than buying an incomplete package, which will leave your Tool unused and unsatisfied. Your decision will also cause a miss or hit to the overall overarching Enterprise Architecture Practice Goal. This will also influence the number of resources and time in order to create any artifact. Out of many key decisions for a sustainable Enterprise Architecture Practice, this will be one.

Before jumping on to the conclusion, I would like to provide some context to my review because everyone's perspective is different. I have been architecting for more than 8 years and have around 4 years working experience in MEGA, both as an End User of MEGA as well as an Administrator of MEGA. In my Architecture work, most of the work started at the Enterprise Architecture level and ended up touching the system level Architecture, but not exactly the System Architecture. My examples of Architectural work mentioned and experienced as part of this discussion's context is from practical real-life project rather than what has been defined in TOGAF or any other Enterprise Architecture Standard. Also, I would argue that even TOGAF doesn't not define the limit where Enterprise Architecture meets System Architecture. TOGAF discusses about Information System Architecture and Technology Architecture, but never talks about the internal details of these architecture. ArchiMate has depicted these levels of complexity in the following diagram. But, unless these Standards provide some real life examples, it would be very difficult to compare what these conceptual terms mean.

What Model comes out of Enterprise Architecture Practice

A pure Enterprise Architecture Practice requires some amount of dedicated resources and time. The outcome of Enterprise Architecture Practice is beyond comparison, especially in today's diverse IT Environment. This Practice should be mandatory for every organization who is going through any transformation, for example, Privatization, merger, acquisition, rebranding, repositioning, organizational structure change, re-inventing itself etc. Whenever these kinds of organizational change happens, the supporting IT backbone needs to be shifted as well. These shifting of IT Building Blocks require a deep analysis rather than a shallow peek. Any IT decision without this analysis would be like putting a band-aid which will remove agility from the organization and prone to collapse or a meager success. I have seen organization, which went through Privatization, rebranding, organizational structural change, repositioning in market, but never had an Enterprise Architecture practice and still thinks why things are not working fine. Unless someone sitting at the top has a super-vision to visualize and analyze everything changing within the organization, I believe every decision to be equivalent to throwing dart in dark. I can't believe that IT plates will realign itself to the underlying needs of the business without any deeper analysis which can be only achieved through a focused group work and that analysis is called Enterprise Architecture. I have heard people sarcasming Ivory Tower Architecture, but, I believe sometimes they are so realistic to be true in the sense that you need tones of effort to implement it and leadership would not agree to that. They need quick fixes. But, at the same time, every work would have some fall-out and disposable.

In concise the whole beauty of analyzing IT backbone, the so called Enterprise Architecture Practice,  is to do a thorough analysis, following standards, discussing, creating models, discussing with leadership, going back to drawing board, bringing entire organization's nerve-cells on the table for dissection, creating existing building-blocks, creating new building-blocks, creating inter-relationship, creating processes, providing an overarching view for every stakeholder and what not.

It is really important for an organization to evaluate the need and scope the Architecture practice. At an abstract level following are the three components of the Architecture Practice, which defines the blueprint of an organization.

1. Business Architecture - How business works
2. Information System Architecture (Application & Data Architecture) - Information System Logical Layer
3. Technology Architecture - Information System Physical Layer

Business Architecture

Business Architecture defines the nervous system of an organization, starting from individual Business Units to how each units are connected and interacts each other. Business Process defines various departmental inter-relationship and information flow. Key artifacts could be, but not limited to:

1. Organization Units
2. Business Capability Model
3. Functional Decomposition Model
4. Business Process (BMPN)

Information System Architecture

Information system Architecture defines the logical IT System landscape in order to support the Business Architecture. In my opinion, there are no such standard names for the logical architecture. The best standard as of today is the ArchiMate for modeling architecture. ArchiMate supports all the TOGAF recommended artifacts. Practically, the key artifacts could be, but not limited to:

1. Application Environment Diagram
2. Data Flow Diagram
3. Logical Data Architecture
4. Integration Diagram
5. System Interaction Diagram

Technology Architecture

Technology Architecture is the layer, which depicts the physical implementation of Information System defined the the logical architecture. Similar to Information System Architecture, there are many ways to represent this layer, but TOGAF & ArchiMate does recommend many artifacts for this layer. These could the key artifacts, but not limited to:

1. Physical Deployment Diagram
2. System Component Deployment

What MEGA offers

MEGA offering is in the form of many packaged licenses. To explain it in simple word, the entire modeling capability of MEGA has been segmented into multiple capabilities. License Offering is based on the bundling of these capabilities. For example, EA Standard module of MEGA, comes with following capability, which I have been working for about two years.

Product names in the attached license screenshot hardly give a clue to what the product is. In general, MEGA advertises the Products like Enterprise Governance, Enterprise Architecture, Governance, Risk & Compliance, etc. Further details could be find at MEGA Site.

Limitations of the MEGA - 'EA Standard'

The whole point of owning an Architectural tool is to capture the Architectural Artifact in a consistent and collaborative way along with following some standard. That means, MEGA helps capture Architectural Artifacts. According to TOGAF,  Architectural Artifacts could be categorized into following categories:

1. Diagrams
2. Lists/Catalogs
3. Matices

So, it would be better to discuss the limitations of 'MEGA-EA Standard' product within classification of artifacts.

Diagram Limitation

Diagram is the heart of any Architectural Artifacts. Diagrams are the primary artifact, which is shared with Stakeholders, generally in the form of Presentations or Documentation. So, diagraming capability of the tool should be second to none. I consider Visio to be the tool when it comes to free-hand Diagraming. It provides the capability to capture and template many complex scenarios. MEGA-EA Standard's canvas is no match to Visio. What we do in MEGA is modeling. So, unless MEGA provides a myriad of Objects it would be really difficult to capture the complex scenario in the diagram. Also, canvas is really not that responsive.

Catalog/List Limitation

Catalog is defined as the list of Building Blocks according to TOGAF. In a Modeling language this can be translated to Objects. Considering that MEGA is a licensed product, it doesn't provide a comprehensive list of Objects to capture the Architectural Artifact. We have always lived at 50,000 feet of diagraming using MEGA. Whenever we wanted to detail the internal complexity of any environment, we used to use the free-floating shapes, similar to Visio, but it was too complex and basic to use in MEGA. Eventually, we had two sets of diagrams. I would like to mention here that, we were forced to keep two sets of diagrams. One, the high level diagram, into MEGA and the second, low level diagram, into Visio like tools. The whole idea of spending a tons of money into MEGA was to make a single collaborative environment for Architectural Artifact, but MEGA could not deliver those capabilities. Here are few list of Objects, which were used often, but, eventually would limit to capture your creativity on canvas.

• Application
• Message Flow
• Diagrams
• Technology
• Assets
• Capability
• Business Process

Matrices Limitation

I see Matrices to be mostly used internally by the Architects during analysis of overall Enterprise Architecture Landscape. Matrices are nothing but the relationship between two Building Blocks according to TOGAF, in other words, in Modeling language these can be defined as relationship between two Objects. MEGA does a good job in providing relationship out-of-the-box. These good features are again limits itself because of missing diversity of Objects in the Modeling Tool.

Takeaways

If you are looking for an Architectural Tool for a large organization with collaborative environment, then these are the questions you should ask before you make a decision. You would be wondering why you would need to answer these questions, but there are lot of inter-woven relationship between these answers and decision you are going to make. I am trying to make things simpler and provide you pieces of puzzle in the form of below answers. I believe, if you understand the answers, you would be able to fit the pieces of puzzle.

• Do you have separate Enterprise Architecture Practice? 
• Who is the boss of Enterprise Architect? Where does the hierarchy fit into the organization? How much decision making and influencing authority does Enterprise Architects have?
• Is your Enterprise Architecture Practice/Team is isolated from the Implementation Project?
• What is the responsibility of Enterprise Architect in an Implementation Project?
• Does your Enterprise Architecture team trained and understand the concept of Enterprise Architecture? This is a weird question, but I believe, they should be trained in at least one Enterprise Architecture Standard, e.g. TOGAF
• Can you define a rough boundary between the artifacts created by Enterprise Architecture and Implementation Project?
• Do you understand System Architecture? I consider all artifacts created during and after Project Design to be System Architecture.
• When does an Enterprise Architect participate and involve in an IT initiative. E.g. Enterprise Search, the search text box on www.xxxcompany.com , sucks. Everyone wakes up tomorrow and starts talking about that. This is the start time. End time would be the day when a powerful Enterprise Search is rolled out through IT Department. So, if you trace everything between Start and End, then, where and how Enterprise Architect is involved.
• How many people would use the Tool?
• Is your Senior Leadership Team onboard?
• Does your Senior Leadership Team understands the difference between Enterprise Architecture, Business Architecture, Information System Architecture, Technology Architecture and System Architecture?
• Who controls, supervises and have bigger share in an IT Projects from concept inception to delivery?
• Do you follow any Enterprise Architecture Standard. E.g. TOGAF, DoD, Zachman Framework, etc.
• Do you follow any Modeling Standard. There is just one ArchiMate. Do you follow this Standard?
• Have you listed all the Capabilities of the Tool you would need and use?

For any thoughts, comments and discussion, feel free to drop me a note.