- 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.
ToolsArchitects 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
Bumps on the RoadSo 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
SharePoint’s SolutionSharePoint 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.