Jargon Explained (Quickly!) : Frameworks, Methodologies, Models.

So not too long ago, someone asked me what I know about the ‘Zachman Methodology’ and the ‘UML Framework’?! – It got me thinking that all of these enterprise architecture terms and their respective ‘technologies’ can confuse a person; what exactly is a methodology or a framework and what approaches are classified as what?

Each time some new group of companies comes up with a new approach to software / process modelling, IT project management and their position in the overall enterprise architecture model it gets even more confusing for the man in the street.  Acronyms such as RUP, UML, TOGAF and SCRUM (well, this one isn’t really an acronym) can be found on CV’s the world over and are closely tied with IT infrastructure and software development projects.  What I’m attempting to offer in this quick article is some separation and understanding of some of the common frameworks, notations and methodologies relating to both business process and software development in an enterprise. I don’t claim to know them all, but I’ve experienced ZACHMAN, AGILE and UML via projects I’ve worked on which sparked my interest in the more pragmatic and structured view of BPM/EAI and Software planning and development.

What’s what?

What we mean by Framework, Methodology and Models/Notation. I’ve nicked what I feel is the most comprehensive definitions from one or two well known ‘wiki’ 😉 sites (plus my additional comments):

Framework : A basic structure of support. Basic indeed!? – In terms of traditional building architecture, the framework is the mechanical structure of the building.  In software design its more of a conceptional foundation for solving a particular software problem.  The .NET framework for example is named so as it forms the basic class structure and rules that allow software to be rapidly built and executed in a secure way on the Windows platform.  Zachman is the framework for the architecture of an enterprise (more on this in future articles).

Model:  A diagram representation of a physical or conceptual ‘real word’ object. Frameworks (structures) of all kinds can be broken down and described in detail.  Physical or conceptual idea’s are best described through images with descriptive notation or ‘Metadata’ (data describing data).  In traditional building architecture, blue prints are the model used to convey what conceptually needs to be built – it contains detailed information about sizes, materials and relative positioning (the model’s metadata).  In terms of the structure of the world, maps provide the model to getting around and understanding distances etc and in software development, models describe the classes, objects and information that make up the desired software solution. It’s important to note that models not only describe the framework / structure of something but the way parts of that thing interacts (the behaviour).  Creation of models (or modelling) pays a large part in the planning of anything and in terms of an enterprise, the planning of business processes and software development amongst others.  UML (Unified Modelling Language) is one of the more well respected, widely used and popular modelling styles (albeit not without its share of criticism) and is used to model software behaviour and structure and business processes.

Methodology: A system of principles, practices, and procedures applied to a specific branch of knowledge. In terms of enterprise architecture, this describes the principles, practices and rules to delivering an enterprise project which ultimately supports the enterprise architecture model and the business model in general.  It’s an approach on how parts of the enterprise architecture should be planned, developed and monitored.  All projects tend to follow a particular type of ‘methodology’ that best fits with the desired results. Agile and Six Sigma are applied methodologies for software development and business process projects.



  1. Great overview. It would be interesting to see your notion on how frameworks compromises models and methodologies, as well how methodology compromises models 🙂


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s