Last week I gave a talk at the Hogeschool Arnhem Nijmegen as part of the conference "Information Systems the Next Generation". This article is inspired by a talk titled "Model Based Development - How to organize and architect survival of MD*" by Wiebe Wiersema given at the same conference. It was a well-balanced, realistic talk about the do's and don'ts of Model Driven Development.
While Model-Driven Development (MDD) is getting more and more attention by both tool vendors and developers, I think it's time to look at 8 reasons why MDD is dangerous. If you recognize one of these points from your practical experiences or if you think you have a solution for (almost) all points, please let me know it in the comments! Although model-driven approaches can differ a lot, I think these 8 points can be applied to almost all of them.
A couple of weeks ago I gave an overview of two scientific publications researching a framework (or methodology) providing end-to-end guidance and assistance to refine and transform business models created by business experts into IT models and then to IT implementation. I tend to refer to these frameworks as Model-Driven SOA, because they focus on using models to construct an IT implementation complying to SOA principles.
However, I didn't elaborate on the practical applicability of these studies. I asked you for your opinion. From the comments on the article and the discussion in the LinkedIn MDA group triggered by this article, it became clear to me that there's a need to describe Model-Driven SOA in more detail before we can sufficiently compare different approaches and discuss the needed models, languages, and transformations.
In this article I present a generic framework describing Model-Driven SOA. I first describe the common terms in system development, like design, engineering, and architecture. After that we can apply these terms to a Service-Oriented Architecture (SOA) based development process. Finally, I want to define the requirements making this SOA system development process a Model-Driven Engineering approach.
The term Domain-Specific Language (DSL) is heard a lot nowadays. A DSL is a language developed to address the need of a given domain. This domain can be a problem domain (e.g. insurance, healthcare, transportation) or a system aspect (e.g. data, presentation, business logic, workflow). The idea is to have a language with limited concepts which are all focused on a specific domain. This leads to higher level languages improving developer productivity and communication with domain experts. In a lot of cases it is even possible to let domain experts use the DSL and develop applications.
The question for this article is: how to develop a Domain-Specific Language?
I'll first explain the DSL lifecycle, consisting of the phases: decision, analysis, design, implementation, deployment, and maintenance. Afterwards I'll give 7 recommendations for DSL development based on my experiences with developing non-trivial DSLs.
What do organizations need to be successful in good times and to survive in bad times? According to Richard Veryard what matters is how people and systems collaborate effectively to address emerging business opportunities and threats, in an agile and innovative manner. He calls this Organizational Intelligence.
I think for reaching Organizational Intelligence we need Model-Driven SOA. The point of Model-Driven SOA is to create technology (Service-Oriented Business Applications - SOBA) that truly supports an organization. We have to specify the business with declarative models, these models should directly lead to working software, either by direct execution (e.g. process engine, rule engine) or by transformations to executable models. Even if these transformations are manual, good tools support tracing between business requirements and implementation, thereby enabling methods to assure business-IT alignment.
However, to do Model-Driven SOA in practice we'll need some kind of framework or process describing what models and transformations we need. Although I have some ideas about this subject, let's first look at some scientific research in this field.
In the remainder of this post I present two recent (last year) scientific publications researching a framework or methodology providing end-to-end guidance and assistance to refine and transform business models created by business experts into IT models and then to IT implementation:
- the Business to IT transformation Framework [1], and
- the Model Driven Service Engineering Process [3].
Model Driven Software Development is getting momentum. Is Model-Driven the future of software development? Or is it the same old wine in a new bottle? I'm not going to answer this question right now. I'll first show you the different types of model driven software development using a simple metaphor: farming.
I'm happy to announce my new microblog dedicated to news and articles on Model Driven Engineering. Model driven software development approaches are getting more and more attention, resulting in more web content. I have also contributed to this movement with a considerable amount of articles on Model Driven Architecture (MDA), Model-Driven Engineering (MDE), Domain-Specific Languages (DSL), Model Driven tooling, and Model-Driven SOA, to name a few topics.
The definition of ‘application' is rapidly changing. As the industry is moving from using an application-centric architecture to a Service Oriented Architecture (SOA), the focus for building functionality is moving to Service Oriented Business Applications (SOBA). This means that applications are a set of services and components working together in fulfilling a certain business need. The technology, specifications, and standards for specifying these components and services may vary, and most often religious discussions are going on about the usefulness of each of them.
As regular readers may guess, my take would be to create these components and services in a model driven way using an approach to Model Driven SOA. However, even in that case you'll need some kind of programming model that defines interfaces, implementations, and references. When building an application or solution based on services, these services can be both created specifically for the application and reused from existing systems and applications. Hence, we need a programming model that specifies how to create and implement services, how to reuse services, and how to assemble or compose services into solutions.
That's exactly what the Service Component Architecture (SCA) is.
In my previous post I gave you a quick overview of the roles involved in Model Driven Engineering. The question for today is how to support these roles with appropriate tooling?
Tools for Model Driven Engineering are often seen as a single category of tools. I'll argue in this article that they can be separated in two categories: DSL (Domain Specific Language) tools and Model Driven Software Factories. Both types of tools have very different user activities. However, before going into details, let's first explain the basics: what is a language workbench and what workbenches do we actually need in MDE?
Model-Driven Engineering, or Model-Driven Development if you like, asks for other roles than we are used to in traditional software development. I think the most important change is the addition of a meta level. Instead of translating business wishes into source code, a software engineer has to define the Domain-Specific Language (DSL) and how to transform a Domain-Specific Model (DSM) specified in that DSL into working software.
Figure 1 exhibits an overview of the artifacts involved in Model Driven Engineering (MDE). A functional specification is translated into application code by a generator. This application code uses a (domain) framework to execute. Both the application code and the framework conform to some architecture, for example a Service-Oriented Architecture (SOA). The models of the functional specification are specified in a DSL, which in its turn is specified in some meta language. The generator is configured with transformation rules, specified in a transformation language.
The question for this article is: what roles do we distinguish in MDE and how are they different from traditional software development?
A couple of weeks ago Anne Thomas Manes did give the year a headstart with her post SOA is Dead; Long Live Services. She states:
Although the word "SOA" is dead, the requirement for service-oriented architecture is stronger than ever. But perhaps that's the challenge: The acronym got in the way. People forgot what SOA stands for. They were too wrapped up in silly technology debates (e.g., "what's the best ESB?" or "WS-* vs. REST"), and they missed the important stuff: architecture and services.
And she ends with: And that's where we need to concentrate from this point forward: Services.
A nice overview of the tail of this post is given on InfoQ. Some people disagree with her solution, they state: SOA is dead; long live the web. They see the Web-Oriented Architecture (WOA) as the solution.
I think we should talk less about the solution domain and more about the problem domain. As a business person I wouldn't care about SOA, WOA, REST, WS*, services, etc. I would be interested in an IT landscape truly supporting my business. And yes, that will call for a certain architectural style, maybe for SOA as an architectural style. However, that's not all: I also want it fast, I want to change it a lot, and I want it at low costs. What we truly need is Model-Driven SOA.
