After years of architectural engagements and having worked at a variety of companies there are a few things that I have found somewhat consistent when it comes to the practice of architecture. First architecture happens, regardless the maturity level of the organization. Secondly, at some point in the development life-cycle someone will produce some kind of box and line diagram to articulate the solution. Finally, there will be some sort of Word document describing the architecture, at some point of time. Generally, from a conceptual viewpoint to some degree of completeness.
How architecture happens is a by enlarge a function of the ceremony, rigor, capability, discipline, and standards of the organization. With that in mind, I’m confident in saying there are some organizational commonalities among the diversity of what is done from this list. Which would include the use of Visio, PowerPoint, Word, and generally a SharePoint site as a platform for collaboration.
In this article I’ll share a few thoughts on the challenges, pitfalls and potential of these business applications in the context of either an informal or formal architectural practice. In which various activities may be performed by an Enterprise Architecture group, a Center of Excellence, or even within a Solution Architecture team. Among the various opinions of what it means to do architecture. I’d believe that it’s reasonable to say that collaboration and communication of the solution to the concerned stakeholders is an essential capability. Regardless of the maturity and structure of the organization doing the work. Next would be the multifaceted modes and mechanism that are used for communication. Which requires more than superficial consideration, but rather a coherent tool strategy. As one of my mentors once said; Only in Disneyland will tools come alive and do your work.
To frame this article I’ve provided the following elaborate box-&-line conceptual diagram. Which is the contextual basis for forming the collaboration and communication machinery.
An examination of this diagram depicts what is a relatively common system in many organizations. In general we would see:
- Modeling Work Products – The Vision diagram often used to communicate an architecture on some level.
- SharePoint – Which hosts several portal sites.
- Document Library – A commonly used Web Part to contain work products and artifacts, such Word Visio and PowerPoint documents.
- Enterprise Wiki Pages – Which provides the capability to subdivide the portal site by subject areas.
What may not be intuitively obvious in this viewpoint are the following:
- Visio Data Linking with Excel or a Database – Which enables Visio modeling elements to be link to an external data source.
- Hosted Kanban / SCRUM Project Management tool – Which is represented in SharePoint as an http link in a Web Part.
While this is a fundamentally sound system that is typical to many SharePoint centric collaboration environments. There are a few challenges and pitfalls.
First it is not uncommon to find that while these applications are used together, they are principally used independently and are often disconnected from an architecture development process, and more often the SDLC. While Visio is used to illustrate a range architectural viewpoint at various points in times throughout the development life-cycle, as well as creating content to communicate to business and technical audiences. With a fragmented tool integration approach, work products may be marginally aligned to the project methodology and artifacts.
In this scenario SharePoint often becomes a simple repository for the resulting models and artifacts, as well as a passive means for communication. Which by enlarge are PowerPoint presentations, Word documents, or simply the Visio diagrams themselves. The challenges in this widely utilized approach to collaboration are multifaceted. However, the primary pitfall is that the collaboration environment is disjointed and fails short of supporting a cohesive and consistent means of establishing a good architectural practice throughout the development life cycle. The underlying contributors to this situation.
1. Poorly structured repository makes it difficult to intuitively locate documents.
2. SharePoint becomes more of a container rather than a true content management system.
3. Documentation often becomes stale shortly into the development life cycle.
4. SharePoint Configuration Management is ignored, which is not necessarily intentional. But this results in the “what version is correct” conundrum.
5. The organizational maturity level is diminished by such a cumbersome document management solution. Efficient and effective communications are hampered.
Additionally, over the project life cycle the collaboration approach may be slowly abandoned, as it becomes less than real-time mode for sharing information. Eventually, growing into something more like an unorganized hallway closet. Stuff goes in, and while over time it may not become lost; it becomes mostly useful in supporting ad-hock queries. Getting architectural direction is more like an archeological dig. Rather than a proactive means for doing architecture. Architecture is about collaboration and communicating the architectural design throughout the development life-cycle. From the conceptual to concrete guidance and prescription of the implementation. A good analogy is that the architecture is like assembling a skeleton, once the bones are structured and the connections are defined. The architecture is fleshed out as implementation adds the sinew and tissue. Proclaiming that you know where the skeleton is buried is not necessarily a good practice.
This is where a comprehensive tools strategy for an integrated EA portal can address the aforementioned challenges. Using the systems context in Figure 1. As the foundation for the tools architecture. Members of the architecture team would implement the following foundational Use Case scenarios. Incidentally, the team is thereby fleshing out its own skeleton.
- Build out the SharePoint site as a set of Wiki pages that follows an architectural development methodology, and tie it to the SDLC.
- In this case the TOGAF ADM will be used.
- Structure the Wiki page with a combination of Sub-pages, using SharePoint web parts such as Custom List, Document Libraries.
- Build object models to flesh out the Custom List as the underlying information model for the Enterprise Architecture catalogs.
- Again work products and catalogs from TOGAF are the basis for designing the information models.
- Use SharePoint enterprise services for version management.
- Embed project management into the architecture development method.
- Use SharePoint enterprise services maintain the content of work products and artifacts.
- Use Visio external data link capability tie the models to the underlying information models.
By implementing this design an architectural practice can expect not only to address the challenges and pitfalls of a fragmented collaboration environment; but also realize the following benefits:
- A means to integrate the business of doing architecture into an agile SDLC.
- Establishing a standardized approach to specifying architectural solutions.
- A means of developing, maintaining and reusing architectural assets.
- Developing a standards information base.
- Providing architectural transparency throughout the enterprise with a means of providing a self-serve approach to communicating architectural decisions.
These are just some of the benefits to building out an organized SharePoint centric collaboration environment that is informed by a comprehensive tools strategy. In subsequent articles I will provide concrete examples of a fleshed out SharePoint portal that implemented the above-mentioned Use Case scenarios.
