Exploiting SharePoint as an Architecture Repository

Enterprise Architecture (EA) as a practice has gained quite a bit of traction over the past decade. Where EA hasn’t taken root yet, Solution Architecture is often practiced. One of the biggest challenges to the adoption of any type of IT Architecture practice or department is the ability to integrate it into the larger solutions lifecycle of any given organization. This is typically a challenge for the following reasons:

1. The culture of the organization isn’t sure about the value proposition for architecture.
2. The working model between architects and the rest of the solutions team isn’t always clear at the beginning.
3. The architecture practice / department lack the tools to do its work or properly communicate back to the rest of the organization.  

Of these three elements of the problem, we’re going to focus on the last one. Usually, there is always some level of resistance to doing anything new within an IT group and of course it takes time to find the right working models for how to implement new processes or capabilities. In the case of IT Architecture, having a tool available at or near the start-up of  a practice makes a huge difference though in helping to resolve the first two issues and ultimately will lead to greater overall success of the endeavor.

SharePoint as a repository is basic - but it does meet several core requirements

Architects tend to use a variety of tools to do their jobs; for example a typical EA may utilize the following software to support a typical data architecture project:

• Microsoft Visio – for free-form design / modeling
• CA ERwin – for ERD or dimensional modeling
• A UML tool – for developing Use Cases, Sequence Diagrams etc.
• Specific tools to support individual software packages (BI, Hadoop)
• Ontology Modeling or mind Mapping
• Network Design tools

All of these tools produce their own architecture “artifacts” or files. There is a also a class of software out that specifically tries to unify all of this information by providing both design interface and architecture repository. The best known of these tools includes IBM System Architect, TrouxMetaverse Mega and Sparx EA. There are quite a few advantages to using this type of software but surprisingly few architecture practices actually deploy them and often when they do try to deploy them they don’t “stick.” In other words, some aspect of the deployment fails or adoption is restricted for other reasons – for example due to a lack of licensing to make the architecture accessible to all of the stakeholders who actually need to be involved. So what happens when an organization deploys an IT architecture practice without any dedicated tool support for it?

In many cases, when an architecture group isn’t given clear guidance on what tools to use; the ability to define and develop clear processes becomes highly problematic. One of the first things an architecture practice or department ought to be doing is defining exactly what patterns or designs are standard for that organization. This set of decisions then tends to manifest itself into design templates in whatever tools happen to be available. Without any standard tools then it almost impossible to accomplish this vital step. Without standard views of the design patterns, then the ability to consistently capture design and apply it in a uniform fashion across projects suffers. The lack of design tool also tends to imply not having a repository as well. Without a repository, architecture artifacts then get managed as content by whatever means may be available in the enterprise:

• Shared folders
• CMS or portal
• QA or other backlog or PLM tools

Of these available options, the use of an existing Content Management / Portal capability represents the best opportunity for organizing an Architecture practice when a dedicated architecture  repository tool is unavailable. Shared folders have access issues and a serious lack of functionality and many QA/PLM also tools share the same cost issues associated with architecture repositories. While any CMS / Portal will work for what’s being described here; I’ve zeroed in on SharePoint due to the sheer volume of the enterprise organizations now using it. Those organizations that don’t already have

SharePoint deployed internally now also have access to SharePoint in the Cloud on Office 365 at fairly reasonable rates (although it takes a while to figure out how to order and configure the options focused on SharePoint only).

SharePoint isn’t always the easiest tool to work with, but it does support some of the key capabilities needed to help establish, unify and organize an IT Architecture practice; those include:

1. The ability to save and version control any type of content.
2. The ability to support complex publishing (e.g. through a basic wiki). 
3. Some application capability (in this case, through the use of List web parts in SharePoint).

While many or perhaps most installations of SharePoint don’t really support Collaboration very well, the SharePoint online solution is now being bundled with Yammer which opens this open up as the 4th major capability. Once you have your architecture “platform” in place, you can go back and align your designs process approach with the “public face” of the practice. A typical SharePoint Architecture site might include the following elements (see the diagram below):

• A Design Pattern Wiki – This is how stakeholders can access your architecture.
• A Business Glossary – This can include the ontology and core business terminology.
• Data Dictionary – This is where architecture meets data; very few organizations have comprehensive data dictionaries, even fewer make them available publicly.
• Architecture Governance Portal – Architecture requires both technical and business input – that Governance can be managed using simple web part Lists for tracking, approval etc.
• Technology Catalog – While SharePoint is not recommended as a comprehensive IT asset management solution, it can be used to capture all reference architectures and information about deployed technology (using a wiki and / or lists). 

In an upcoming post, we will talk more about how architecture patterns are managed using this type of approach or traditional EA repositories.

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc