Throughout my career there have been a couple of quips that I have followed when presenting certain ideas; “Eat Your Own Dog Food” along with its close cousin Practicing What You Preach. In the first article of this series I promoted the idea that architecture is about collaboration and communication. I then laid out a conceptual architecture and a high level business case in terms of the benefits of; building out an organized SharePoint centric collaboration environment that is informed by a comprehensive tools strategy. As I flesh out this concept, I’ll provide a goal statement that will use in setting objectives for this effort.
Goal: The collaboration environment will provide a unified system that brings together architectural design elements into a platform that incorporates process, governance, project management methods, modelling, version control, information recognition, text management, and collaboration. As well as adding metadata as; information about the organization and characteristics of the stored information. Together these will enable an enterprise architecture practice to manage its unstructured and semi-structured data in a logical manner. Aligning business objectives to capabilities implemented by solution architectures.
Before moving into Use Case analysis. Lets consider the business context in terms of the capabilities that will be provided by the proposed unified system solution. Succinctly, the SharePoint site is one component of the system that will provide several features to support a Capability Framework. The notion here is that an EA Portal built on SharePoint will be positioned as an enabler for the Capability Framework. Thereby bridging strategic intent, which is described in the Business Vision domain, to execution which is defined in the Business or Architecture Capability domain. The following Capability Framework model depicts the interaction between the high level objectives for these three domains.
Now I will analyze some of the Use Cases for implementing the SharePoint component as part of the collaboration environment solution. In the first article I provide several foundational scenarios which I’ll treat as high level business Use Cases. I also described several challenges to the effective use of a SharePoint centric system, which I’ll treat as risk. These are not included in the this model, as Risk Analysis is out of scope for this particular article.
Now I’ll start eating my own dog food. As an activity of the architectural practice and development methodology. I’ll begin by creating an Epic derived from a high level business Use Case, which is associated with my highest risk. (The Epic: Structure the site to support the architecture development method). This is an Architectural Epic that implements the foundational navigation model for the enterprise architecture portal site. The User Story for this iteration. (User Story: As a site user I want to be able to easily recognize and select ADM domains from an ordered list). Because the second Epic (Build Capability Catalog Information Models) shares an extension point with the Create SharePoint Wiki Pages system Use Case. I decided to include some features for this Epic as well.
I should also note that many of the high level functional requirements have been derived from the TOGAF ADM. And in future iterations the ADM will be integrated with the Solution Architecture practice that is based on a tailored version of RUP for the SDLC, as well as high level framework for a Phased Gate approach. At this point specific tools for the Solution Architecture (SA) practice are not in scope. Therefore the Use Case model does not show a SA system boundary such as we have for the SharePoint Portal. What is also noteworthy is the notion of a Phased Gate approach which is a common practice in software engineering. Which is not evident in the structuring of the site. This is because Phase Gates are at a higher level of abstraction, and are a sort of wrapper for the ADM. Making this structure primarily concerned with Governance. Therefore in my thinking. Higher level phases should be excluded from the organizational structure of the site, which flattens the navigation. However, I will provide a different viewpoint to address the concern of integrating the ADM with a Phased Gate Governance approach.
Using the familiar TOGAF ADM Crop circle diagram I have added Governance Checkpoint activities in the legend. In a sense these activities are use to wrap the ADM, which is a concern at the enterprise architecture and program management level. This is an important step in integrating a Governance Framework. Another key take away here is the iterative approach of the ADM life cycle. Additionally, by using this approach the phases may be used as elements of a high level work breakdown structure in planning, while the ADM domains are used in a Kanban methodology as I will show in later articles.
- Discovery Phase – Governance Checkpoint
- Preliminary
- Elaboration Phase – Governance Checkpoint
- Iteration(s)
- Architecture Vision
- Business Architecture
- Information Systems Architecture
- Technology Architecture
- Opportunities and Solutions
- Solution Architecture
- Implementation Phase – Governance Checkpoint
- Iteration(s)
- Migration Planning
- Solution Development
- Iteration(s)
- Transition Phase – Governance Checkpoint
- Iteration(s)
- Implementation Governance
- Architecture Change Management
- Iteration(s)
My next step. Based on the User Story I created an EA site using several SharePoint Portal Web Parts in the implementation. The following screen shot depicts a SharePoint Home Page which contains simple information about the Architecture Development Method taken from the TOGAF Framework and the ADM. The page contains the ADM Domains and Catalogs Web Parts. Where the ADM Domains are represented as an ordered list of SharePoint Wiki Pages. The top most pages are relevant to Enterprise Architecture practice as a whole. The second Wiki Page Web Part contains a structure for information catalogs, which are used to manage unstructured data as well as related meta-data.
In the next article I will work on some additional User Stories for the Architectural Epics (Structure the site to support the architecture development method) and (Build Capability Catalog Information Models). I’ll will continue to eat my own dog food by introducing the use of the Kanban and SCRUM approach as a project management methodology. Showing how the ADM and PM frameworks are integrated as part of the EA site. I will also create object models use to design how the site manages unstructured data in the form of Catalog List. I’ll also touch on the structure of Document Libraries which are used to manage semi-structured data, such as Visio models and Word documents.
