Over the past decade, enterprise architecture as a practice has gained quite a bit of traction. 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 because:

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

Of these three elements, we’re going to focus on the last one. Usually, there is 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 of a practice makes a huge difference in helping to resolve the first two issues, and ultimately will lead to greater overall success of the endeavor.

Tools

Architects tend to use a variety of tools to do their jobs. For example, an 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 also a class of software that specifically tries to unify all of this information by providing both a design interface and architecture repository. The best known of these include 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. When they do, they often don’t “stick.” In other words, some aspect of the deployment fails or adoption is restricted for other reasons, such as a lack of licensing to make the architecture accessible to all of the stakeholders who actually need to be involved.

Bumps on the Road

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, it’s almost impossible to accomplish this vital step. Without standard views of the design patterns, the ability to consistently capture design and apply it in a uniform fashion across projects suffers. The lack of design tool tends to imply that there’s no repository as well. Without a repository, architecture artifacts 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 options, the use of an existing content management/portal capability represents the best opportunity for organizing an architecture practice. Shared folders have access issues and a serious lack of functionality, and many QA/PLM 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 enterprise organizations now using it. Organizations that don’t already have SharePoint deployed internally have access to it 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’s Solution

SharePoint isn’t 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. That opens it up as the fourth major capability. Once you have your architecture “platform” in place, you can go back and align your design process approach with the “public face” of the practice. A typical SharePoint architecture site might include the following elements:  

• 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.