[April 12, 2017 Update: changed “metadata-driven” to “model-driven (metadata-driven)”]
[October 24, 2016 Update:
- Technology Building Block for Microsoft SQL Server added
- Building Blocks RACI Roles added
- Existing relationships updated for conformance with ArchiMate specification
- Typos and grammar corrected
- ARM for SharePoint 2013/2016 image replaced in this blog posting
This is now a “version 2” (make it work better) model.]
It’s an interesting exercise to try and create an Architecture Reference Model (ARM) in ArchiMate for large, model-driven (metadata-driven) LOB applications like Microsoft SharePoint, Salesforce, Microsoft Dynamics CRM, SAP, Oracle Financials, a SQL Server fault-tolerant cluster, the Microsoft Azure platform, etc.
Even though some applications (platforms) are architecturally quite different from one and another (e.g. SharePoint configurability vs. SAP modularity), the fact that metadata drives the configuration and reconfiguration these applications is the most interesting aspect from an architectural point-of-view (vs. manually or semi-automatically configuring a collection of software components or modules).
For the next while, I’m focused on creating Architecture Reference Models that in turn can be used as templates for creating logical and physical enterprise architecture models for these platforms.
Here’s version 1 (“make it work”) of the Parallelspace ARM for SharePoint 2013/2016. It’s based on my 15+ years experience as a SharePoint architect – working first for the SharePoint product group and then a number of Microsoft solution partners (including my own company Parallelspace Corporation).
Note: This is now a “version 2” (make it work better) model.
Please email me your feedback (firstname.lastname@example.org) or add it to the comments below.
Michael Herman (Toronto)
p.p.s. The above view is what I refer to as a Construction view. This isn’t a formal view in the ArchiMate specification but it is a view I use when I am building or constructing or updating a model. It’s an “all in” view of the model who’s only stakeholder audience is the Enterprise Architect responsible for maintaining the ARM (architecture reference model). One downside of this view is that it has too many overlapping lines – but that’s OK. Appropriate stakeholder views should then be derived from the elements and relationships in this “all in” ARM.