The idea that in order to get clear about the meaning of a general term one had to find the common element in all its applications has shackled philosophical investigation.
Ludwig Wittgenstein
Preamble
Bones of contentions are not unknown to systems engineering, some across the divide between business and systems realms, other between parties on each side. Whatever the motives, the protagonists often take refuge behind extensive and punctilious standards, two a penny, one for every nook and cranny of information systems or enterprise architecture. The ensuing misunderstandings are especially harmful for the alignment of business and systems: when looking for a sound bridge with secure conceptual lanes linking business processes and supporting systems, analysts are facing a maze of shaky flyovers.
Assuming that standards are meant to provide analysts and architects with more freedom in their choices, de-facto proprietary schemes are clearly self-defeating. Taking example from open sources solutions, a better alternative would be to agree on open concepts to serve as building blocs for modeling languages and methods set to objectives and environments.
Open to Different Languages
With regard to systems modeling, languages can be regrouped into four categories:
- Knowledge management relies on formal languages to chart domains of discourse. Since such domains are by nature specific, there isn’t much to expect for KM standards beyond formal logic and inference engines.
- Business processes modeling focuses on business logic and process control. Associated languages can therefore be seen as equivalent to a combination of UML’s activity and state diagrams.
- UML covers the whole of systems specifications. Cut to the bone it could secure some consensus as a standard.
- Domain specific languages (DSLs) can be seen as silo implementations of UML’s class diagrams supporting comprehensive code generation.
Each family clearly fulfills a well defined purpose; nonetheless, there seems to be no principled obstacle to their consolidation around a common conceptual hub. Yet, the practical challenge for large and complex organizations (the ones concerned) has been to find a consensus on shared definitions. That obstacle could be overcome if, instead of looking for some hypothetical overlapping between domains of discourse, their semantics would be set from open concepts.
Open to Different Methods
Beyond the expected benefits on costs and quality, two of the main objectives of methods is (1) to smooth the differences in skills and expertise and, (2) to facilitate communication across large organizations.
Broadly speaking, three schools of thought can be considered, depending on focus and perspective:
- Agile approaches put the focus on skills and responsibilities and largely ignore communication issues across organization or along time.
- Phased development models take the opposite view as they slice the tasks and detail development flows and intermediate deliveries.
- Frameworks take a broader perspective, with some focusing on the definition of processes, others set on reasoned organization of models and artifacts.
All approaches could benefit from open concepts, if for different reasons:
- As should be expected, agile methods don’t give much attention to development artifacts except the sanctified software. Nonetheless, when some unfortunate upshot make other kinds unavoidable, teams are set between the rocks and hard places of schemes deemed unsuitable. They would be in a better position if they could use open concepts to define the artifacts best suited to their situation.
- Given their procedural nature, phased approaches are constrained by predefined tasks and deliverables whose adjustments are all too often limited to windows dressing. Process templates built from open concepts would be much more robust and versatile.
- Frameworks focusing on processes (e.g TOGAF) have to compensate for their lack of conceptual anchors by being meticulous until they become overwhelmed with details. Open concepts could help them to factor out a compact backbone supporting a much smoother learning curve.
- Frameworks focused on artifacts (e.g Zachman) face the opposite difficulty of mustering a consensus around their principles and semantics. That could be easier with open concepts.
As for languages, methods and frameworks serve different purposes and it would make sense to keep some options open depending on the enterprise organization and the characteristics of projects. That could obviously turn into a strenuous and costly endeavor for methods wholly and meticulously imported from outside or driven by harnessing tools. But the argument holds as well for single options with hefty upfront costs and steep learning curves: in any case methods are most successful when developed step by step from existing practices and organization, along each enterprise culture. That should make the case for mixed and pragmatic solutions.
How Concepts can Unlock Frameworks
The litmus test for assessing modeling languages, methods, or frameworks is their leverage on independence. Just like proprietary options and environments are widely and rightly opposed, choices of methods or frameworks should not preempt changes or alternatives, or incur cumbersome and costly transitions.
That can hardly be achieved by simplex communication channels between modeling schemes, except for small, stable, closed and unambiguous ones. Instead, versatile methods and frameworks could be build bottom up from practices and experience around a small set of well accepted open concepts managed with a conceptual thesaurus.