OBASHI is not Enterprise Architecture (EA) - but it will be used by Enterprise Architects. We actually think that every EA project would benefit from using the OBASHI methodology and software. Here's why.
There are three main camps in Enterprise Architecture:
- Static Models like, for example, Zachman
- Dynamic Models like, for example, TOGAF
- Hybrid Models like, for example, DoDAF
No matter the chosen approach
, all suffer from the same problem: clear and simple communication that the board/stakeholders can easily understand. That might be communication about the cost of the project; the value of its benefits; or simply an easy to understand "Big Picture" about what a programme of work might entail - the stages to be gone through and how the work is broken down into projects.
Obtaining sanction to release staged tranches of project spend to continue a programme of work is never easy, and effective communication of current and future expenditure is essential. But communication problems can begin just trying to get a programme off the ground in the first place.
So why is there a communication problem? EAs are usually "some of the smartest people in the room", and let's face it they need to be.
At the heart of EA is technical detail. The "nuts and bolts" if you like - the code, apps, processes and hardware that support the most important thing in modern business: the data and information. And if you look at most EA websites, forums and publications, you will see that EA professionals enjoy getting under the skin of these technical details. For them to do their job, it's really important stuff.
But the board do not need the technical detail that EAs thrive on - they need clarity.
So surely it makes sense for EAs to find a standard way to clearly communicate the ways in which EA projects and programmes can benefit the business.
Can EA learn anything from practices in other industries?
Let's look at the car industry.
When a car manufacturer develops a new vehicle the designers show how the car will look; demonstrate how it is constructed; and help communicate the benefits, and improve understanding, of the decision-making process of the experts involved.
Designers create sketches; selected sketches are transformed into CAD computer models; then 3D digital modellers automatically convert the CAD models into quarter-size clay models of the car. The models are made as lifelike as possible for the reviewers who will decide which ones move forward to become life-size "production" clay models.
"The full-size production clay models serve as templates for the actual production vehicles, so it is necessary for the clay modelers to embody the designers' images with legal, engineering, and manufacturing requirements in mind."
All the key stakeholders use the CAD and clay models as their discussion "documents".
Everyone can see clearly how things are put together, and communicate more effectively.
The board and other stakeholders in the business have little interest in the details. Do they really care about the precise number of milliseconds it takes for an airbag to inflate; or the stress tolerances of the cogs in the gearbox; or the thickness of the yarn used to stitch the seats?
What really matters is that the product can be sold for the right profit and that it can be brought to market as efficiently as possible.
So why is this relevant to Enterprise Architecture?
EA has struggled to produce an equivalent model. When communicating with the business it uses too much jargon about technology, placing too much emphasis on the IT equivalents of airbag inflation, cog stresses and yarn thickness. It hasn't been able to explain simply and clearly how everything is put together to make the business work, in a way that non-technical people can understand.
This is where OBASHI can help the Enterprise Architect.
OBASHI has been developed to create business clarity. To model, and clearly show how people, process and technology interact, and to help people at all levels in a business understand the financial value of data flow. In other words, OBASHI helps you see the context in which people, or the component parts they are associated with, contribute to the business.
To be able to do this, you must be able to understand all the relationships and dependencies of the component parts (the "Enterprise Artefacts", from an EA perspective) and how they relate together, in sequences that enable flow of data/information to occur. The OBASHI methodology shows how that can be achieved, while the technology in the OBASHI software lets you deliver the capability very quickly.So, if you
- want to be able to articulate the business cost/value of an EA project in a simple and understandable format
- need to communicate about it with people in all departments and disciplines, across silos and at various professional levels
- are looking for a Big Picture that puts people, process and technology in a business context
OBASHI is a standard, practical, and common-sense approach that lets you do all three.
PS: We devote a whole section of the appendix in The OBASHI Methodology to Enterprise Architecture. The manual is available to purchase here.