 |
The Object Management Group (OMG)’s
Model-Driven Architecture (MDA)
has gained significant mindshare within the IT industry
this past year. Although the MDA is a really wonderful
theory, there are clearly
many challenges which need to be overcome.
Assuming that you don’t find these challenges too
daunting, are you ready for the MDA? The critical
issues that you must consider are: |
|
-
Do you currently have highly
skilled modelers? MDA only works when you have
people with the right skills, and gut feel tells me
that at best only one or two percent of all
developers have these skills.
-
Do you have people on staff
that could become highly skilled modelers? If
you don’t have sufficient numbers of modelers now,
perhaps over the next few years you might be able to
identify and then
train and mentor people in those skills.
-
Are you able to attract and
retain highly-skilled modelers? If you don’t
have the uber-modelers that the MDA requires you can
always hire them, although many other organizations
will also think along these lines and will be
desperate to hire these people away from you so
you’ll need to be very good at retaining them.
-
Do you have people who are
both strong modelers and strong coders?
Even when you're creating these sophisticated models
you'll still need to code, be it action semantic
language (ASL) code in your platform independent
models (PIMs), object constraint language (OCL), or
even platform specific source code in Java or C# to
implement the logic which your tool(s) didn't
generate.
-
Are your stakeholders
sophisticated enough to understand PIMs? In the
late 1980s, when complex modeling tools were first
popularized, we discovered that our business
stakeholders had great difficulty understanding the
abstract models which we created. We learned that
we needed to use
simpler techniques and simpler
tools with our users, and that when we did so that
they could become actively involved with specifying
systems.
-
Can you find a modeling
toolset which fulfills your actual needs?
How usable/learnable is the tool(s)? MDA
only works if you can find modeling tools which meet
your actual needs. You will likely discover that
you need to find a single modeling tool – although
the OMG’s XML model interchange (XMI) sounds great
in theory the reality is that there doesn’t yet seem
to be a combination of tools which doesn’t exhibit a
loss of information when sharing models between
them.
-
Do you have a viable testing
strategy in place? Part of building a system is
validating that it works. Unfortunately I don’t
know of any modeling tools which support some form
of test-driven modeling (TDM), or perhaps we should
call it test driven MDA (TDMDA), so how are you
going to prove that your system actually works?
See
Jason Gorman's thoughts on the issue.
-
Are you willing to tie your
fortunes to that of the tool vendor? With the
MDA approach to development you become extremely
reliant upon the modeling tools which you use. This
wouldn’t be so bad if it was easy to share models
between various tools, but frankly the tool vendors
have little motivation to actually support this
functionality because they prefer to have you locked
into their product. Worse yet, because each
tool has it's own unique extensions (e.g. their own
ASL, various non-UML models) you won't be able to
easily transition staff between tools.
-
Will senior management stay
the course long enough to succeed? To
truly reap the benefits of MDA you need to have a
cross-system, multi-year strategy in place.
How well have these sorts of strategies worked out
in the past?
-
Are you allowed to be agile?
Are you adopting the MDA to soothe the worries of
the bureaucrats among us, or are you doing it to
actually be successful at software development.
Hopefully it's the latter, and if so shouldn't you
try to take an
agile approach to the MDA?
When you stop and think about it
there is very little opportunity for MDA within business
application development. Yes, there are very likely
wonderful opportunities using MDA tools for software
simulation or the development of embedded software;
these environments tend to have developers with the
requisite skillset and there are several tools
specifically targeted at these market niches. However,
this is a spectacularly small percentage of the overall
market.
 |
|
The Object Primer 3rd Edition: Agile Model Driven
Development with UML 2 is an
important reference book for agile modelers,
describing how to develop 35
types of agile
models including all 13
UML 2 diagrams.
Furthermore, this book describes the techniques
of the
Full Lifecycle Object Oriented Testing
(FLOOT) methodology to give you the fundamental
testing skills which you require to succeed at
agile software development. The book also
shows how to move from your agile models to
source code (Java examples are provided) as well
as how to succeed at implementation techniques
such as
refactoring and
test-driven development
(TDD). The Object Primer also includes a
chapter overviewing the critical database
development techniques (database refactoring,
object/relational mapping,
legacy analysis, and
database access coding) from my award-winning
Agile Database Techniques
book. |
|
|
|
Agile Modeling: Effective Practices for Extreme
Programming and the Unified Process is the seminal
book describing how agile software developers approach
modeling and
documentation. It describes principles and
practices which you can tailor into your existing
software process, such as
XP, the
Rational Unified Process (RUP), or the
Agile Unified Process (AUP), to streamline your
modeling and documentation efforts. Modeling and
documentation are important aspects of any software
project, including agile projects, and this book
describes in detail how to
elicit requirements,
architect, and then
design your system in an agile manner. |
 |
|
The Elements of UML 2.0 Style describes a collection
of standards, conventions, and
guidelines
for creating effective
UML diagrams. They are based on sound, proven
software engineering principles that lead to diagrams
that are easier to understand and work with. These
conventions exist as a collection of simple, concise
guidelines that if applied consistently, represent an
important first step in increasing your productivity as
a modeler. This book is oriented towards
intermediate to advanced UML modelers, although there
are numerous examples throughout the book it would not
be a good way to learn the UML (instead, consider
The Object Primer). The book is a brief 188
pages long and is conveniently pocket-sized so it's easy
to carry around. |
I actively work with clients around the world to
improve their information technology (IT) practices as
both a mentor/coach and trainer. A full description of
what I do, and how to contact me, can be
found here.
|
