Somebody asked the other day what the difference was between OBASHI and UML. Here’s our answer.
While OBASHI wasn’t created to compete with UML there are areas where the two methods overlap, and in these areas it’s interesting to explore the different emphasis of the two methods, in capturing and portraying information.
First, a bit of background on ‘Unified Modeling Language’ (UML).
UML is usually adopted by technical IT professionals, traditionally being used within the IT industry by software developers and designers who specify, visualize, modify, construct and document the artifacts of an object-oriented software-intensive system under development.
As such, it has various diagrams that allow technical aspects of the system to be documented, such as reusable software components, database schemas, activities, entity relationships etc., as well as how it is used by its users.
UML has 14 types of diagram, which can be sub-divided into Structural and Behavioural diagrams. Here’s a breakdown of what they are and the OBASHI layers in which they operate, and an indication of how technical the viewer of the diagram needs to be in order to understand it.
Structural UML Diagrams – operate primarily at an application level, and are usually detailed technical diagrams describing the attributes and methods of how component parts of a software package are defined and interact.
- Class diagram: Application layer (Very Technical)
- Component diagram: Application and Hardware layers (Very technical)
- Composite Structure diagram Application layer (Very technical)
- Deployment diagram: Application and Hardware layers (Technical)
- Object diagram: Application layer (Very technical)
- Package diagram: Application and Hardware layers (Very technical)
- Profile diagrams: Application layer (Very technical)
Behavioural UML Diagrams – capture how and why applications are used by the business.
- Activity diagram: Business and Application layers (Technical)
- Communications diagram: Application layer (Very Technical)
- Interaction Overview diagram: Business and Application layers (Technical)
- Sequence diagram: Business and Application layers (Non-Technical)
- State diagram: Application layer (Technical)
- Timing diagram: Application and Business layers (Technical)
- Use Case diagram: Business and Application layers (Non-Technical)
UML tends to operate at a technical level describing software and how users interact with it, and therein lies the main difference to OBASHI.
The drive behind OBASHI was clarity; adopting an approach which would allow the people, process and technology deployed, in an organisation, to be modelled in a way which would be simple for the lay person to understand.
By using the six OBASHI layers in a Business and IT diagram (B&IT) it’s easy to show how IT supports business processes. And it’s the full IT stack, not just the application layer.
So rather than being just for the technically minded IT professional, OBASHI is designed to be simple to understand by everyone within the business. As such it is a great communication tool at every level.
With a focus on business, in just one type of OBASHI diagram (the B&IT) we can address the Who, Why, What and How of business operations:
Who: The Ownership layer
Why: The Business layer
What: The Application layer
How: The System, Hardware and Infrastructure layers.
Once the business is modelled in a B&IT, the Dataflow Analysis View diagram (DAV) allows dataflow to be modelled through each of the artifacts and shows how dataflows combine together to create the systems and services that operate across multiple systems.
DAVs allow you to append the behavioural aspects of UML such as Timing, State and Sequence etc., while B&ITs can be used to document the Structural aspects of UML, such as Component, Class and Deployment etc.
Personally, I think UML is great for capturing some of the finer system detail, which can then be appended to OBASHI diagrams.
So, in summary, I believe the target audience for users of UML is the technically-minded professional, more often than not within the software development environment, who wishes to document the complexities of how software components interact with each other, and how they are used.
OBASHI, on the other hand, has a target audience of anyone, in any environment, in every organisation, who wants to create increased clarity on the interaction of people, process and technology, so that their organisation can make better decisions.