The Wikipedia definition of a metamodel illustrates the difficulty one can have in understanding the concept: A meta-model typically defines the language and processes from which to form a model. Huh?

The very plain English version from an Enterprise Architecture point of view is that a metamodel is a collection of all the stuff that makes up your enterprise and their relationships to one another. Basically it’s an ontology which our trusty source Wikipedia defines as: A standardized representation of knowledge as a set of concepts within a domain, and the relationships between those concepts.

As we’ve discussed, Enterprise Architecture is typically broken down into layers focusing on strategy, business and technology or business, application, data, technology depending on the framework you have chosen.

The metamodel is where the EA rubber hits the road so to speak. You populate your EA content by populating the various elements in the metamodel and the related properties which then provide you the ability to create different views of that information that are relevant to specific audiences. Let’s illustrate this with a simple example:

As you can see we have specific elements in each of layer of our EA. These layers are sometimes referred to as sub architectures. It is also critical to clearly define each of the elements so there is a shared understanding about what the terms mean. Looking at the diagram it becomes clear that our metamodel provides a structure for our content and enforces rules about which elements can be related to what. For the more technically inclined – think of the metamodel as your database schema

For example – a Business Initiative would obviously not be directly related to a Device in the Technology layer. However by navigating through the layers and elements you can see that there is an indirect relationship between the two. Having said that, this metamodel would allow us to analyze what business initiatives would be potentially impacted if there was a problem with a specific device.

As well as providing a common definition for the elements that comprise your enterprise, the metamodel and associated modelling tools also provide the ability to make a lot of the documentation that typically collects dust actionable. An example of this would be the ubiquitous Business Process diagram. You know – the one that always seems like a great idea for the business analyst to show how well they know the business and the one that doesn’t get updated as the change requests start flowing in.

Instead of using Visio or another drawing tool to create your swim lane diagrams you would open your modelling tool and create a new business process diagram and model it using BPMN. You would then link it to its related elements and voila! You now have a diagram that can be used in many more meaningful ways to the benefit of the enterprise. You can easily assess the impacts of any changes, you can quickly see where the process is used and by which groups in your enterprise and you can see which data elements are used to support the process. Therefore there is an incentive to, through your EA governance processes, to ensure that the process diagram is kept up to date.

Most EA frameworks provide a metamodel and the more advanced tooling supports the implementation. Below is an example of the TOGAF (The Open Group Architecture Framework Metamodel:

A tool such as IBM Rational System Architect supports the TOGAF metamodel by having the elements and their relationships predefined when a new TOGAF project is created. These elements are extensible in the sense that you can easily add organization specific properties to them which would be driven by the information requirements of the various stakeholders.

Another important point to note is that because the elements are related to one another you have flexibility in where you begin populating the metamodel. Again, this is driven by the requirements of the stakeholders. If your EA initiative is nascent you could begin by modelling the application and technology related elements and expanding upwards towards elements in the business architecture as your EA capability matures.

The EA artifacts you create (Swim Lane Diagrams, Node Connectivity Diagrams, Data Flow Diagrams etc.) are built from and linked to the elements in your metamodel. This makes the artifacts dynamic in the sense that they are driven by real data and you have the capability to drill-down through them to see all the related information. Multiple future states can then easily be modelled to assess the potential impacts of any changes.

In order to ensure that an organization gets the most value out of their technology investments there needs to be alignment between the technology and the business. This is a problem you hear constantly – everyone knows there needs to be alignment but very few understand practically how to do it, model it or measure it. Enterprise Architecture is one of the disciplines that will enable an organization to accomplish this. The metamodel is where you relate business and technology architectures which will allow you to make smarter, more well-informed decisions going forward.

Enterprise Architecture has the ability to make things visible that were previously hidden and this is done through choosing, extending, populating and reporting on the metamodel.

Theodore awoke with a start covered in sweat. Glancing over at the clock it read 2:46 am. He possessed an astonishing level of clarity about his life that he had never experienced before. He bolted from bed and emailed his supervisor. “You are the man and I can no longer work for the man.” Theo purchased himself a plane ticket to Tibet and then bought a Yak from Amazon. He donned the chuba that he had crafted with his own hands for just such an eventuality and headed to the airport. As he mounted his steed to begin his literal and figurative ascension things went south back home. The mission critical systems that Theo had been working on as a software developer crashed causing massive disruption to his former employer, aka The Man. You see, Theo was a software developer – a software developer who, unbeknownst to his teammates, sucked the big one.

As the emails started pouring the development team struggled mightily to determine what was happening and how to fix it. It began with not knowing where the source code for the system was and then when finding it finding multiple versions. Once that was sorted out the problem was knowing where to look and then deciphering the hacked together mess of spaghetti code in order to begin to understand the root cause. To make a long story short, 18 hours later the problem was resolved. But the real problems that had been festering for a long time had just been brutally exposed.

After receiving the tongue lashing of her life from the CEO, the CIO stalked down the hallway looking for the supervisor of the development team grabbed him by the ear and dragged him into her office. “You have 2 days to come up with a plan to ensure that this never happens again. It will encompass standards, processes, backup resources on systems and anything else you think is necessary. You’ve really let me and the entire company down. Now get out and get to work.”

Jason assembled his team of 10 developers and looked around the table. Quite frankly he was at a loss and didn’t know what to do he opened the floor to suggestions. Harvey, one of his more obstinate developers started with, “What is the point? We’ve tried to implement standards before and it never amounts to anything. We’re too busy, pulled in a million different directions. Besides, is anyone else going to buy a Yak and go to Tibet? Probably not so I don’t see much risk of this happening again! ” Nancy piped up with, “Plus we’re trying agile development and that doesn’t seem to be helping. Why throw more stuff into the mix.”

Jason closed his eyes and thought about how the whole “agile” thing had been going:

Full stop! This is where teams typically shoot themselves in the foot by thinking small. Invariably irrelevant suggestions like commenting code, naming conventions etc. get tossed out as good ideas. Clearly this will never be enforced leading the team to the conclusion that standards, while good on paper, are a waste of time. So what would I do? I’d Keep in mind that “big” means big in the context of our problem here. Not “big” like world peace or preventing pandemics.

Role Clarification

The first thing I would do is to explain clearly what the role of the software developer is in the organization and clarify how they are expected to add value. This means explaining, as often as necessary, that they bring value by developing custom business logic that solves real business problems. That means looking at things through the prism of the company’s mission and objectives. If you make car parts and the development activities don’t help make car parts better, faster cheaper or more safely there is a problem. Admittedly some of this is beyond the control of the software developer. In their direct sphere of influence this means not writing redundant code, using proven practices and frameworks etc. It never ceases to amaze me how developers are resistant to the idea of using something created by someone smarter.

If there are business analysts in the organization I would provide further clarification on the role of the business analyst versus developer. As a leader want my developers to be the absolute best technical experts in their field they can be. This means supporting and encouraging them to get to where they need to be but also shielding them from performing activities that won’t take them there. My role as the leader is to break down the natural resistance between these two groups so we can work productively. Strong business analysts working with exceptional developers can make magic happen.

Frameworks

Framework is one of the more overused words in the world of software development. In this context I mean the overall structure and approach for developing the required business solutions. This means taking a convention vs. configuration approach to developing solutions. Wikipedia defines this as “a software design paradigm which seeks to decrease the number of decisions that developers need to make, gaining simplicity, but not necessarily losing flexibility.” In other words – applications have been built for a long time and there is a best way to go about them. So do that and modify only what you need to suit your specific purpose.

To illustrate my point I’ll discuss ASP.Net MVC (Model-View-Controller) framework for developing dynamic web applications. For all the Microsoft haters out there – relax – there all kinds of great languages, environments and frameworks. Creating an ASP.Net MVC application gives you the following benefits.

1. A predefined solution structure as seen in the following screen shot which will provide immediate familiarity to all developers on your team.
   

    

2. Separation of Concerns. This basically means that stuff goes where it should. HTML and script go in the Views, business logic goes in the Controllers and the data access goes in the Models. Naturally a developer can still screw this all up but the framework provides a rich environment so the opportunities to deviate from the pattern are reduced.

    

3. Standard Naming Conventions. Controllers and their actions as well as views have standard naming conventions making it simpler to find what you are looking for

There are clearly more advantages but this illustrates the benefits of using frameworks in the context of this article.

Another example is ORM or Object Relational Mapping. This means using something like the Entity Framework for data access operations. What this provides is a mapping from your database tables to strongly typed objects which support CRUD operations, relationships etc. An entity data model will look like the following screen shot:

The relationships between your objects are defined by the primary key/foreign key relationships in your database. So in this example an Order object will have a related collection of OrderDetail objects. This entices the developer or DBA to create those relationships properly in the database as there is a direct benefit to the developer when developing solutions. It also follows a standard naming convention by naming the types created the same as the tables in your database which further simplifies things.

Design Patterns

Another simple approach is the adoption of a set of design patterns useful to your specific circumstance. Wikipedia defines design patterns as a general reusable solution to a commonly occurring problem within a given context. Or in other words: many of the problems you are trying to solve have been solved already so use that approach. There are many design patterns and not all will be applicable. Review them, pick a few that seem pertinent to the work you do and start using them. The developers that maintain your code in the future will thank you for it.

Governance

Clearly, a significant part of the problem is the absence of management frameworks such as IT Governance, Project Portfolio Management and Enterprise Architecture. These are beyond the scope of the developers to influence in our example with the incredibly short timeline. Going forward they will need to be established in order for the organization to truly get the most value from its technology investments. This will be covered more in a future post.

Conclusion

In our fictitious example we were presented with a catastrophic situation caused by a fragmented development team creating business solutions with no standards. The goal was to quickly come up with some ideas for minimizing the risk of this catastrophe reoccurring or minimizing the impact if it did. There are many more areas to be looked at but we discussed the some that can be implemented easily providing some quick steps in the right direction. Let’s summarize what we are planning.

1. By clarifying the role of the developers vis-à-vis the business analysts we will, in time, allow the developers to focus more closely on what they are paid to do. By helping them understand how they add value will also provide context for some of the other ideas we’ve discussed
2. Agreeing to adopt Frameworks such as the ASP.Net MVC will bring the team a long way in creating a sweeping set of standards far larger in scope than some of the typical suggestions. Naming conventions, separation of concerns, standardized HTML output, solution structures, database design and ORM are some of them. These are significant and can be accomplished easily making your team much more able to step in and maintain someone else’s solution.
3. Defining what kind of problems that are typically faced and adopting proven design patterns to solve them will also go a long way in creating more standardized business solutions reducing risk and easing maintenance.

On a more intangible note – people respond well to using these frameworks and patterns and being encouraged to be professional experts in their areas of practice. The development of professional, robust and maintainable solutions fosters satisfaction and team cohesion which leads to the development of more professional, robust and maintainable solutions. It becomes a self-perpetuating cycle of excellence.

So with a few relatively simple concepts we can accomplish some huge steps towards making ourselves a more professional and trusted team within the organization.

The ultimate goal is to make sure that the organization is not at risk the next time one of your team members decides that working for you is akin to some medieval form of torture and leaves at the drop of a hat. Best of luck Theodore – we’ll talk again soon!