In my last blog, I cited some examples of inconsistent semantics that are prevalent in applications as well as in their usability. Applications tend to be siloed in nature and their schema often corresponds more tightly to specific dialects. The end users make it worse by often using it for multiple purposes, thereby muddying the semantics even more. Also as I mentioned in the blog, this becomes a nightmare for those striving for an Information Integration strategy (a cohesive platform that unifies information across tools, departments and processes). Such strategies and solutions have been championed by some of the biggest vendors in the applications and infrastructure space (IBM, SAP, Oracle) -- via their MDM (Master Data Management) or EIM (Enterprise Information Management) strategies.
But how does one effectively address this EIM challenge?
To us, the answer is relatively simple. By making "minimum ontological commitments". Of course the devil is in the implementation details.
- First of all, it involves a set of interconnected ontologies (or sub-ontologies) which together provide a specification for a domain (in our case, Software Engineering). Examples of these sub-ontologies would be SCM, Process, Person, Document, Test, Requirement, Collaboration, etc. These ontologies provide a consistent and coherent vocabulary that can be shared amongst applications, processes and people within a domain [Gruber]. The focus here is on consistent sharable vocabulary and not necessarily a mechanical mapping of schemas across applications. Each application may still have its own dialect that is not relevant beyond its sub domain -- therefore the emphasis on making minimum ontological commitments.
- Second, an infrastructure that maps and captures this semantically relevant information from each application (or tool) into the semantic repository (aka Information Integration Framework).
- Third, semantically enabling the applications and the overall platform so that the same information is accessible to all participants and agents using the same vocabulary and taking it a notch higher -- creating composite views or dashboards from this integrated information to alter the traditional metaphors of how we see things.
- Fourth, leverage reasoning capabilities from the ontological specifications to get beyond the data that is empirically captured and enrich the knowledge base.
So it is quite straightforward :)
In concrete terms, such commitments can answer simple questions, such as:
Who broke the build, what tests were conducted for a particular set of checkins, who reviewed them, what requirements or bugs initiated the actions, who authorized the final move to production of a particular set of changes, what customers are impacted, which components are most vulnerable with respect to defect density at a particular development stage, etc.
Of course, we can get these answers now but it either requires a lot of walking the hallways and late night phone conversations with remote teams to gather the information across teams and silos, or making some costly commitment to an integrated toolset from one particular vendor.
Or, the questions above can be more directly and easily (and automatically) answered in your own environment with your own processes and tools -- by integrating the zAgile semantic infrastructure.
Its about Information Integration in your world.
Its about building relevant knowledge through this integration that will allow you to effectively collaborate, coordinate and manage your software development and delivery cycles.
-Sanjiva, Orinda, Oct '08
Comments