I am starting to write a new blog at ebizQ. It’s called Anatomy of Agile Enterprise and will be about strategic IT in support of organizational change and responsiveness. I aim at posting quite often, even on a weekly basis.
Consequently, this blog will likely be less about IT in the future, but I will keep summarizing interesting events and other learning experiences, refer to interesting articles and other resources, and record my thoughts here, insofar they go outside of the scope of the other blog.
I will generally not cross-post to both blogs, so if you are a subscriber to this feed, you may want to follow the other one as well.
345b
Today, KAOS, a newly formed Finnish community of practice on Enterprise Architecture organized a world café about setting up an EA function. The event took place at OKO Bank in Helsinki. I was asked to host a café on EA governance, which I found a rewarding experience. The small group discussions were intense and it was interesting to hear about experiences in a large variety of companies.
I opened the discussion with the following set of questions:
- Which roles and responsibilities pertain to EA governance?
- What kind of linkages exist between these roles?
- At which organizational levels are various architectural artefacts governed?
- Which governance processes pertain to EA governance?
- Is EA governance centralized or distributed? Are there any underlying structural or other contingencies?
- How is EAG related to other types of governance, e.g. IT governance?
Half of the questions would have been enough, however, as there would have been no end to the discussion that ensued.
It was concluded that EA governance specifies expectations between people in terms of roles and accountabilities, defines decision-making entities and clarifies communication. It should have a strong link with business development and guide the development of new IT. EA governance should have influence on the project portfolio and be aligned with the project model. It helps enterprise architecture down from the ivory tower and infiltrate the organization.
The governance roles seemed to vary from organization to organization, and we generally deemed that the question about contingencies is, indeed, relevant: there is no universal governance model. However, we were not able to delve into the question in any depth at this time.
Today, SOA SIG, MallinnusOSY and SOLEA jointly organized an event on Model-Driven Design. The principles, advantages and challenges of Model-Driven Architecture (MDA) and Domain-Specific Modeling (DSM) approaches were discussed in four great presentations as well as in the panel discussion that followed.
After I had opened the day, Juha-Pekka Tolvanen, CEO of MetaCase and co-author of “Domain-Specific Modeling”
gave an introductory presentation to the day’s topics, with a special emphasis of Domain-Specific Modeling. He argued that, due to the modeling language specifically tailored to the domain, DSM raises the abstraction of software development to a new level, gives full control of development to the company and increases productivity by hundreds of percents. Not a bad proposition.
Next, we had a great honor and privilege of having a keynote presentation by David S. Frankel from the US, a pioneer in MDA and the author of “Model Driven Architecture: Applying MDA to Enterprise Computing (OMG)”
. Mr. Frankel spoke specifically about semantic interoperability in enterprise integration, as “most growth in model-based systems is in model-driven integration”. Whereas the state-of-the-art tools support syntactic mapping, they do not address what should map to what. Integration costs are high to start with, consuming 30-40% of IT budgets, and an estimated 80 % of the integration effort is consumed by semantic interoperability requirements, which is very labor intensive. Even modest improvements in semantic interoperability wil thereby have large economic repercussions. Frankel explained the nature and structure of machine-readable semantic metadata, based on principles of language and called for a link between semantic ontologies and message structures in the next generation integration tools.
After the lunch break, Jan Wirix of Integral ICT, Belgium, recounted his experiences in a large-scale business process automation undertaking, in which model-driven principles had been applied in the form of MERODE methodology. Based on his experience, a clear distinction should be made between IT demand and IT supply, the conceptual and logical specifications independent on the physical implementation. Wirix concluded that MDA is an important factor to preserve simplicity and control projects and a significant step in moving software engineering “from stone age to iron age”. However, MDA can take place if and only if an architect exists.
Finally, professor Matti Rossi of Helsinki School of Economics presented his findings in an academic study that investigated whether domain-specific models are easier to maintain than UML models. The results were statistically significant and suggested that DSM models are, in fact, easier to comprehend and maintain than UML models.
The day was concluded with a panel discussion moderated by Harri Kreus of Auroranet and participated by David Frankel, Juha-Pekka Tolvanen, Matti Rossi and Juha Mykkänen (University of Kuopio). First, Kreus asked the panelists to take sides in the juxtaposition between MDA and DSM. Not surprisingly, no-one vehemently defended either approach, but everyone acknowledged the applicability of both, confessing oneself as being “Pro Modeling” rather than “Pro MDA” or “Pro DSM”.
At the end of the day, the question comes down to how to efficiently generate good quality code that addresses the business needs. The panelists agreed that although the level of abstraction of languages has risen, there is still a long road to go, before business can be readily executed in software. In the world of PowerPoint as the starting point, how should a language look like that would appeal to the domain experts? Professor Rossi drew an analogy from urban planning saying that high-level models should not describe the world in too detail, but merely as tentative; otherwise, they will be taken as something already decided-upon. Independent of the technology used, Frankel called for human competence in precise expression of business requirements, something a business process specialist or business analyst should be good at.
As a general conclusion, it was deemed that MDA has merits where interoperability is called for, but DSM becomes more applicable the more specific the domain is.
216a
