Unleashing the EA Genius with the Repository

EA work can be challenging. Too many things to capture. Too many things to validate. Too many stakeholders to make happy.  As many others have noted, I think there is a viable way to make it easier. The following reflection hopefully provides a strong case for a liberating solution.

The Many Moving Parts of EA

Alignment is such a sweet simple word, that it can be truly deceiving -- masking the complexity behind EA's genius of simplification. And although we are now moving into consensus as to what is “enterprise architecture”,  organizations will continue to interpret and emphasize various aspects of EA, leaving many other aspects possibly neglected.  And as many of our discussions and blogs have pointed out,  different technology camps will place varying scope for enterprise architecture, which only adds to the confusion.  There are indeed so many moving parts that it takes some kind of savant to be fully engaged with all aspects, something like IBM's Deep Blue or the recent Watson which (or who) won the ultimate Jeopardy season.

So far, at this point in our learning journey, we have come across requirements to clarify business context, alignments to mission, goals, and objectives; the need to understand strategy execution, operating models, maturity stages; the importance of stakeholder management and engagement, understanding their viewpoints, and expressing these through capability requirements. Moreover ,we have revisited the tools to develop and communicate future state vision, which made us re-think architecture principles, business rules, standards, and trends.  Recently, we have covered modeling techniques to bring out current-state constraints by delineating functions, modules, and the interfaces that connect these components.

Gap Analysis must be done well.

We are now, therefore, at cross-roads, continuing to find a clear set of methodologies and standards that we can apply effectively to properly execute Gaps Analysis.  Obviously, this is critical. When done without competence, the organization remains clueless on things that are missing; or perhaps know things are missing, but can't determine by how much. Indeed, the gaps and the size of the void  determine the work ahead, define the roadmaps, and how the organization charters its course.  Poor roadmaps will be at best clunky hit-and-miss affairs, and at worst case, leads the enterprise to the depths of hell and quagmire -- a place where recovery is rare.

So really, to my mind, Gaps Analysis is truly important, since the results determine which intiatives/ projects are defined, proposed, evaluated,  and undertaken. Moreover, these initiatives and projects are further assessed against others in the portfolio, to see which brings the highest value, against their level of risks. The prioritized intiatives and projects form execution strategies aligned with those at the enterprise level.

As these strategies are executed, the mechanisms of governance come into play, monitoring these initiatives and projects move through its lifecycle stages, where processes check their development, their adherence to strategies, policies, principles, and standards; and by which decisions for go/no-go, funding, and selections are made.

However, with all these EA elements to sort through, how do EA teams manage to do the required vetting and analysis?  For example, can EA confidently have answers to challenging questions such as:  How many entities are related to the notion of risk?  How many processes support Customer Service directly, and indirectly in the 2nd order? When measuring leadership capability goals, how far are we from achieving competetive status?  When we speak of capability gaps, how big exactly are the gaps? Can it be sufficiently described to be convincingly actionable? Indeed, how does EA provide these answers?

The EA repository is our friend.

The Case for the EA Repository

Given these discussions, we need to  place high significance for the EA repository and find an approach to establish an effective repository suitable for the enterprise. Moreover, we can argue the fact that the body of documentation for EA are "living documents" i.e. dynamic, and can change constantly given the many moving parts that we have discussed earlier. Given these requirements, the repository solution needs to be highly extensible, and therefore open, to accommodate and interface with new tools and EA products that the organization might want to use.  And while adaptive to several tools, the core structures defined for the repository should be standardized and selected based on customized requirements of the organization.  

The repository should be designed to be implemented as a website and should be accessible even from remote internet devices. A a central tool with expected high usage, the repository has to be  is placed in a robust database platform that can store and capture data and images from all artifacts, to include data elements from diagram models (e.g. entities, relationships, constraints, etc.),  and perhaps even include rendering information (to draw the models out).  It is important to stress the importance of developing a web-based EA repository that provides easy access to EA artifacts which can truly facilitate and enable planning and decision-making throughout the enterprise.

Establishing the Repository

Enterprise Elements LLC is a company which has done this. I checked recently but the site appeared unavailable. At any rate, they worked with the DoD before, using the repository tools that they have developed to bring in EA data elements from various tools.

http://www.enterprise-elements.com/

However, another viable option is to build a homegrown repository, customized to the needs of the organization, avoiding lock-in dependencies with a repository vendor, and having full control of its evolution. It's not terribly difficult, and can be spec'd out easily enough to be outsourced without too many issues.

The key is to find the API's from the EA tools that will expose data elements and other useful information - perhaps even rendering data, so the drawings can be rendered back from the database, outside of the original tool. This rendering capability obviously, is an extended project already.  However, for the purpose of capturing the data so it can be sliced and diced in analysis,  straightforward data capture, storage, and reporting is not hard to accomplish.

By default, Enterprise Architect stores its repository data in a .eap file. One fellow shares his techniques to extract information from Sparx's Enterprise Architect tool, and loads the extracts into his own database.

http://www.drowningintechnicaldebt.com/RoyAshbrook/archive/2013/01/28/how-to-make-ea-enterprise-architect-documentation-available-to-those.aspx

Embarcadero exposes its data via a csv export, and a reporting facility.

https://www.embarcadero.com/images/dm/technical-papers/metadata-repository-ron-lewis-2.pdf

The same way with IBM's Rational System Architect.

https://www.ibm.com/developerworks/rational/library/rational-publishing-engine-generate-compliance-documents-3/

More repository development ideas for model collaborations, versioning, and extensions are described in the following links - specific to ArchiMate discussions.

https://github.com/archimatetool/archi/wiki/Feature-requests-and-roadmap

http://www.slideshare.net/matteobusanelli/extracting-archimate-views-from-custom-ontological-ea-models

And lastly, I found this great set of discussions for Automating Enterprise Architecture Documentation, and gives a great insight on extracting EA information from SAP systems (PI).

(The PDF can be retrieved on google search: Proceedings of the Eighteenth Americas Conference on Information Systems, Seattle, Washington, August 9-12, 2012.)

Conclusion

The EA repository is an enabler for an effective EA implementation methodology. The strategic goals can easily be linked to various points in the EA Framework, tracing which EA artifacts are associated to these goals. Similar traceability can be established for stakeholder viewpoints, business processes, information flows, systems and applications, technology infrastructure components, security implementations, tools and tool evaluations, and governance workflows.

There is truly a strong case for building a robust EA repository. It is a critical central tool for any architecture development — for each domain-specific work, and even more so for enterprise architecture, which needs to have a facility that can help it integrate architecture development across all domains, as well as help go through the various dimensions that need to be validated for alignment. Lastly, this datafication of architectural elements provide the ultimate tool to fine-tune in a granular way how we measure EA, allowing enterprise archictects to have the data to show how EA impacts alignment and integration, and facilitates evidence-based reporting on EA’s contribution to the value chain.