I’ve been tracking a new OMG standard called the UML for Systems Engineering. The Request for Proposal (RFP) stage has just closed, with one submission from a pretty powerful group of OMG members. The question I’m trying to understand: will this new standard advance the erp4it concept? Digging into the issue, I found yet more standards converging on the same set of issues…
A key quote from the RFP:
“The customization of UML for systems engineering is intended to support modeling of a broad range of systems, which may include hardware, software, data, personnel, procedures, and facilities…A UML-based language for modeling systems will support the exchange of analysis, specification, design, and verification information using standardized notations and semantics that are understood in precise and consistent ways. This will improve communication among people who participate in the systems development process and promote interoperability among tools that support this process.”
Sounds like most of what we’ve been discussing here. It also would seem to have some overlaps with the Software Portfolio Management Facility.
The RFP goes on to say that it is coordinated with an ISO standard effort known as AP-233. Turning to some of the ISO language, we see that the areas of its concern include:
- Requirements management
- Functional architecture
- Physical architecture
- Configuration management
Reviewing the available ISO material, I get the feeling I always get with ISO standards, that I’m looking in at a party and I can’t hear what people are saying. The stuff all seems to hang together, but I just don’t get the “aha” moment of comprehension as to what the real purpose is.
This confusion is heightened when I look at what the SysML folks (the only submitters) have presented. It’s firmly based on UML 2, and offers some interesting extensions. For example, there is a Parametrics metamodel that appears to be targeted at hard engineering; I don’t see it holding any relevance for the erp4it space. But again, maybe I just don’t have the Rosetta stone I need. It also proposes “extend[ing] Actions and Object Nodes to support continuous functions and inputs/outputs,” again something that seems more of an EE thing. It calls for the support of Functional Flow Block Diagrams, a spec that appears very closely related to classic IDEF functional decomposition.
There is a Requirements metamodel that might work well with SPEM. And then finally it calls for a Hardware/Software Mapping Diagram, but does not detail what this is – a metamodel?
Some examples are manufacturing-centric, not targeted towards operational production systems.
Part of my confusion I think stems from what “systems engineering” connotes. So I go to the International Council on Systems Engineering (INCOSE), which is prominently cited in the ISO material as a driving body. Under the topic “What is Systems Engineering?” I get:
Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem:
Operations
Performance
Test
Manufacturing
Cost & Schedule
Training & Support
Disposal
Systems Engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. Systems Engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.
If we read this in an IT context, we would pretty much get IT Service Management. So what is the relationship between IT Service Management and Systems Engineering? No links at INCOSE to any ITSM stuff; no hits at http://en.itsmportal.net/ on “INCOSE.” Again, a couple of areas that should probably be talking to each other.
We can get a little more understanding of the “systems engineering” domain by looking at the INCOSE membership: mostly military, hard engineering, and aerospace. No banking, retail, insurance, health care, etc. Also absent are most IT vendors, with the major exception of EDS. (Even IBM is missing, and they usually join everything).
They have a handsome brochure. Featured picture is of the space station, which is further indicative of the military/aerospace orientation. But I have to ask - surely any formalism capable of representing the space station could represent enterprise IT…? And the rest of the brochure clearly sees the challenges of large commercial enterprises as in scope. There’s a lot of quotes I could pull out; recommend you go read the brochure yourself if you’ve gotten this far. But the participation just isn’t there in INCOSE of our core audience.
I’ll close with some questions that I’ll be directing to a variety of folks, and hopefully will have some answers to post back here:
1. Is DCML redundant with the aims of UML for Systems Engineering and ISO-AP-233? EDS participates in both INCOSE and DCML; does the right hand know what the left is doing?
2. Are the DMTF and the TMF tracking UML for Systems Engineering and ISO-AP-233? Have they had any interactions with INCOSE? Is the OMG/TMF work currently in progress aligned with the UML for Systems Engineering initiative?
3. Has there been any interaction between ITSMF and INCOSE?
4. Does the Architectural Design Language (ADL) community see UML for Systems Engineering as a partial answer to their ongoing critique of UML?
5. Why does SysML not specify a more robust hardware (meta) model?
6. Why is configuration management mentioned in ISO-AP-233 but not in SysML?
Stay tuned,
Charlie
