How was Training?

more

good, give a clear understanding of the material - Director Enterprise Archite3cture, PPDI, USA, Sep 2010

Recommend PEAF?

more

Yes - It's always about learning new perspectives and share knowledge to help advance the field of enterprise architecture. - Senior Business Analyst, Canadian Intellectual Property Office, Canada, Feb 2015

  Introduction   Context   Methods   Artefacts   Culture   Environment   Adoption  

Desktop

Mobile




 

<< Previous <<

>> Next >>

In this section, we look at the Artefacts of PEAF. The artefacts deal with the structures required for Structural and Transformational description. The WHAT.

Interestingly it is the thing that most frameworks and ontologies focus on, which when you see the other quite important things like Methods, Culture and Environment might make you wonder how much value they contain.

It is understandable however, that people concentrate on Artefacts as they are very "tangible" - the things being produced and consumed - but also because many frameworks come from IT departments and IT people, and IT people love datamodels, ontologies and Meta-models, and those types of things are reasonably easy to produce. Methods, Environment and Cultural things are much harder to produce and therefore tend not to be.

The artefacts defined in PEAF constitute the EA Meta-model and some of its content such as Principles.

There are many Meta-models that already exist (for the reasons defined above) and the lack of a Meta-model has never really been a reason why EA initiatives fail. For this reason, PEAF does not concentrate on defining a complete and detailed Meta-model (no point reinventing the wheel). However, PEAF does defines some important things that are usually missing and also exposes a higher level structure that people can use to understand how the detailed Meta-models they wish to use fit and relate.

Unfortunately, this is not an easy task because all the myriad Meta-models out there do not share any common backbone or structure (such as MACE and MAGMA). Even if you can figure out which parts of which Meta-models you wish to use, integrating them into a whole is also fraught with difficulty, again because there is no common meta-meta-structure (such as MACE and MAGMA).

This is exacerbated by Tool Vendors not providing facilities for the importation and separate management of different Meta-models from different sources along with the functionality to then present and manage and use them as a coherent whole.

This whole problem area is an area that Pragmatic is currently working on, driving Meta-model providers to structure their Meta-models around a Structural Ontology (MACE), a Transformation Ontology (MAGMA), all expressed at different levels of abstraction (Enterprise Context, Contextual, Conceptual, Logical, Physical, Operational) and driving Tool Vendors to think about how to then use them and allow people to use and manipulate them.

This will be a long and hard road (some say impossible), but one that will reap fantastic benefits for Enterprises globally. These 2 things (doing the impossible and fantastic rewards for customers) are the things that mean it's something that Pragmatic has a passion to do.

In the meantime, Pragmatic will continue to map existing Meta-models to MACE and MAGMA to provide Enterprises with, at least, a starting point to understand how they relate and therefore how to adopt them.

 

Do you use multiple Meta-models?

What Meta-models do you currently use?

Do they have limitations?

How do you integrate them?

 




 

2008-2016 Pragmatic EA Ltd