TIMLMWG Activity

Lonnie VanZandt, Enterprise Architect, Sodius
TIMLM Working Group co-Chair

Crafting a Collaboration Space for the Conceptualization of a Collaborative Engineering Service for Modeled Engineering Artifacts throughout their Enterprise Lifecycle

MLM Vision: Purgatory

We see:

“a community of Systems (and discipline-specific) Engineers struggling to persist and to reference the artifacts of engineering over the lifecycle of each enterprise;

a community of Stakeholders and Decision-makers forced to make decisions irrationally and intuitively due to
a lack of access to the defensible arguments
that both legacy documentary and innovative
model-based systems engineering
should provide."

Doré, Gustave, 1868, Dante purgatorio

MLM Vision: Paradise

We see:

"a day when engineers use distributed systems that automatically persist artifacts in compact, modular form along with the provenance of each modification;

a day when engineers can reference the current and the historical representation of both individual artifacts and collections thereof along with the relational graphs
between artifacts;

a day when stakeholders make rational
decisions using the Systems Engineers’
explicit sound dialectical and rhetorical
arguments based on the provenance of
content and change.”

Doré, Gustave, 1868, Dante e Beatrice

Paraphrasing Charlton and Adras, management is a process by which managers reflectively model and share a representation of their own processes to enable themselves to perform their eponymous information-processing activities of monitoring, evaluating, predicting, and controlling their enterprise and its systems. [@Charlton2003]

Furthermore, managers manage for particular purposes. Purpose-driven, they acquire systems to address the needs of the enterprise and they manage their stakeholders, engineering lifecycle tools, and artifacts during the acquisition processes to attain certain goals. [@VanZandt2016]

Management?

  In “Mob Programming, A Whole Team Approach”, the authors describe, “mob programming”, an evolution of pair programming as, “all the brilliant minds working together on the same thing, at the same time, in the same space, and at the same computer” [@Zuill2016].

  The TIMLMWG intends the term "Collaborative Engineering" to be a variation of this mob programming concept. Blending in Sun Microsystems’ John Gage’s marketing campaign that “the network is the computer” and allowing the “same space” to be the “same virtual space”, the TIMLMWG describes collaborative engineering as: ...

Collaboration?

"All the brilliant minds working together on the same thing, at the same time, in the same virtual space, and on the same worldwide network."

[@VanZandt2016]

Collaboration

•  FROM:              Individual Artisanal Engineering
• Cooperative Artisanal Sequential Engineering
• Peer Pair Parallel Engineering
• Supply-chain Joint Venture Engineering
• TO:                                                            ...Collaborative Engineering 

Progression of the
Practice of Engineering

With the aforementioned Vision, the INCOSE Model-based Systems Engineering Initiative assigned the TIMLMWG the mission to:

• “Prioritize the issues and establish scenarios and best practices that address the concerns of the Systems Engineering, Deciding, and Engineering communities.”

With this Vision and Mission spurring the TIMLMWG, it began an enterprise to study the formative practice of MBSE and to specify a hypothetical and ideal concept of operations for a collaboration environment for the management of modeled engineering artifacts across their lifecycle.

The collaboration was arduous despite the members’ great zeal to contribute. A Collaborative Enterprise Architecture System (CEAS) was needed.

Mission of the TIMLMWG

Sought CEAS Capabilities

• Solicit Stakeholders’ opinions of Sought Capabilities
• Propose in a draft form Sought Capabilities
• Argue with Evidence and Warrants Claimed Capabilities
• Choose and Exclude Proposed Capabilities
• Curate Chosen Capabilities
• Document Curated Capabilities
• Persist Capabilities and their Documentation and Arguments
• Present one or more Curated Capabilities to Stakeholders in a Persuasive Argument

• The CEAS SHALL have an acquisition cost of either zero dollars or a cost so low that purchasers—who are volunteers in the organization—might willingly pay for it out of personal funds.
• The CEAS SHALL have an ongoing maintenance cost of either zero dollars or a cost so low that purchasers—who are volunteers in the organization—might willingly pay for it out of personal funds.
• The CEAS SHALL NOT intentionally favor any particular vendor of commercially available software.

and...

Stakeholders' Requirements
of a CEAS (1)

• The CEAS SHALL be accessible to its enterprise architect users from any terrestrial Internet-connected location.
• The CEAS SHALL be available 7 days a week, 24 hours a day and its availability SHALL NOT favor any particular timezone.
• The CEAS SHALL NOT depend on the exchange of Email or documents for synchronization of Definitive Truth throughout the community.

​and...

Stakeholders' Requirements
of a CEAS (2)

• The CEAS SHALL limit access to its information to authorized Users.
• The CEAS SHALL limit roles to groups of its Users.
• The CEAS SHALL store the Provenance of Change when its stored content is modified.
• With the CEAS, non-IT users (as well as DevOps-savvy ones) SHALL be able to “on-board” smoothly and immediately into use after simple identity registration and authentication.

Stakeholders' Requirements
of a CEAS (3)

Tradespace Candidates

• Selection and Rejection Criteria and Discussion
• An Argument for Classical Argumentation in Enterprise Architecture artifacts
• Case Study with Samples and Screen Shots
• Future Work
• References

Paper Provides

(1) Organizations today seek systems that are sufficiently complex to be unattainable from the engineering activities of individual artisan engineers or even often beyond the production abilities of entire individual companies.

Modern systems demand modern organizations that span the boundaries of individuals, teams, companies, countries, cultures, and timezones.

Conclusions

(2) “Collaborative engineering” does not describe a group of engineers each of whom contributes their skilled capabilities to a product in progress at some ordered phase in time.

Instead, collaborative engineering is “all the brilliant minds working together on the same thing, at the same time, in the same virtual space, and on the same worldwide network”.

Conclusions

(3) INCOSE’s Tools Interoperability and Model Lifecycle Management Working Group, with its mission to elicit, curate, and present the concept of operations for an ideal system for model lifecycle management needed a Collaborative Enterprise Architecture System to collaboratively specify such an enterprise architecture. The TIMLMWG performed a trade space evaluation of the most promising free, academic, and commercial solutions extant in 2016. No turnkey solution was found.

With Zoho Creator, the TIMLMWG crafted a CEAS that enables it to collaborate on the Capability Analysis and on the Services Architecture of the MLMS enterprise architecture.

Conclusions

(4) Several of the candidates considered in the evaluation give the TIMLMWG architects hope that some tool vendors and software entrepreneurs share the TIMLMWG’s vision and the TIMLMWG is optimistic that enterprise architects will:

one soon day be able to effectively collaborate on their architectures and to offer decision makers defensible arguments for those architectures.

Conclusions

Author Info

• Enterprise Architect, Sodius
• (ex) Chief Architect, No Magic
• (ex) UPDM Co-chair
• INCOSE Tools WG Co-chair
• OMG BPMN2 Certified
• OSLC Developer
• IBM Jazz CLM Integration Partner
• PTC Windchill Integration Partner
• Tasktop Sync Partner
• ~30 years Software and Systems Engineering
• 17 years Consulting
• Hobby Ontologist