Opinion: Rickard hits out at the MDA view of reality

Discussions

News: Opinion: Rickard hits out at the MDA view of reality

  1. Rickard has written down some of his thoughts on MDA. He hits out at the idea that we can capture all requirements in a model (platform neutral), that can then generate "the right code" for your particular environment/application. He views that models are NOT necessarily better than code as a representation anyway! The idea that you will either become the uber-modeller (architect) versus the peons (developers) is not consistent either.

    Many would argue that large companies that have architects that never touch code, are not the best architects! More of the better coding shops share the roles of architect/developer and take on all responsibilies.

    As he says, it is probably good (if you are pro-MDA) that he isn't going to be on the MDA panel at the JavaZone conference!

    Read MDA: into the twilight zone

    The expert panel at the Chicago No Fluff was asked to talk about their thoughts. It seemed like all were skeptical, and most felt closer to how Rickard feels :) Has anyone out there been using MDA in the real world? Any success stories?

    Threaded Messages (144)

  2. The problem is that MDA doesn't yet match the real world process of building software. For example, this is impossible to build anything real with:

    model -> transformation -> result

    Even with "custom coding" it is not practical:

    model -> transformation -> custom mods -> result

    However, if we constructed the original logical progression differently, we could actually come up with the basis for something that could, with enough time, become workable:

    model(s) -> transformation -> model(s)

    (where, to get to the end, the result is simply one type of model)

    We'd need some meta meta, like:

    type = f(model)
    transformation(s) = f(type(s))


    Now, extend it:

    model(s) -> transformation -> custom mods -> model(s)

    Add iteration and recursion, and a "resiliency" of the process for managing "custom mods", and you have something that actually reflects how many developers work.

    Even with all that, the uses of MDA are still rather limited, at least for the time being. Each class of model and corresponding transformation(s) represent a huge effort. Perhaps, some "open MDA" will evolve that will allow a broad stage of actors to contribute their domain expertise, but I don't know how realistic that would be.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  3. a little correction...[ Go to top ]

    I think the more correct formula for meta-meta will look as following:


    custom(mod(s)) == f(model),
    transformation(model) == type(s)


    and if you extrapolate this you can close approximation to a number of developers involved...

    :-)
    Nikita.
    Fitech Labs
  4. The problem with

    model -> transformation -> result

    is that a model is a view of a system for the purpose of human communication, and it is only possible to develop a complete result (system) with sufficient models (views) to provide coverage.

    An iterative-incremental process can mitigate this problem by modelling a little and coding a little in a round trip manner. Some "good" CASE tools will also attempt to give you:

    result -> transformation -> model

    which is one of the most perverse and damaging innovations I have seen because it encourages the faking of design post facto through report generation. This is basically using a CASE tool as a crutch in an attempt to compensate for a lack of process.

    Also the reverse transformation is not complete, because there are soft models (such as use cases) that are far less easily derived from code than hard models such as class diagrams. And even the "hard" diagrams are partially soft - anyone who has tried reverse engineering a sequence or class diagram will probably have seen this, when far too much detail is sucked in, or in the wrong area, for the communication purposes you have in mind.

    Anyhow, this is the best we have been able to do for at least 10 years and I don't see MDA solving this at all. Actually, I expect things to get worse. The crisis is largely a methodological issue, not a technical one. MDA is *potentially* advantageous if used responsibly in conjunction with a realistic process. What we'll see though is a spiffier zimmer frame.
  5. result -> transformation -> model

    >
    > which is one of the most perverse and damaging innovations I have seen because it encourages the faking of design post facto through report generation. This is basically using a CASE tool as a crutch in an attempt to compensate for a lack of process.

    You forget that model!=process. Model, if defined like "a bunch of little colorfull boxes drawn on a piece of paper", is exactly that and nothing more. If your process makes the drawing of the little boxes mandatory just for the sake of it, you basically have no process - instead you have some pretty old people playing with crayons and being payed for it.
  6. I have successfully applied MDA principle in J2EE/SNMP based Network
    Management System by XSLT based code generation. It was quite successful
    since 62% of the real operational system is generated code.

    Refer to XML Journal article reprint

    http://www.codegeneration.net/articles/mdpuxslt.pdf

    or

    XML Journal, August 2002, Volume 3, Issue 8

    "Model Driven Programming using XSLT"

    http://www.sys-con.com/xml/pdf/trees.pdf
  7. whats the benefit of code generation[ Go to top ]

    I have always why MDA emphasizes generating code so much. If they really have a new way of modelling and specifying all relevant aspects of a system, then they should give me a virtual machine that is able to run the spec as is, instead of throwing out pages of (cryptic) code that has to be run through a compiler and all. My suspicion is that the reason is simply that it makes it easier to "prove" the benefit of the approach to a manager by showing him the generated lines of code.

    christian
  8. They never replace hand coding.[ Go to top ]

    My suspicion is that the reason is simply that it makes it easier to "prove" the benefit of the approach to a manager by showing him the generated lines of code.


    Actually the reason is much more obvious.
    All current CASE MDA tools can create nothing but sceleton code. Actual content of functions still must be created by hand.
  9. They do limit the amount of hand coding[ Go to top ]

    My suspicion is that the reason is simply that it makes it easier to "prove" the benefit of the approach to a manager by showing him the generated lines of code.


    I think that the reason is that the output from the transformations is meant to run in current deployment environments.
     
    > Actually the reason is much more obvious.
    > All current CASE MDA tools can create nothing but sceleton code. Actual content of functions still must be created by hand.

    This is simply not true. Compuware's OptimalJ will generate fully functioning code, from database tables through JSP's (with EJB's and Struts Actions in between). The JSP's are almost certainly not laid out the way you want them; but, in my experience, the presentation layer is the least expensive layer of development.
  10. They do limit the amount of hand coding[ Go to top ]

    My suspicion is that the reason is simply that it makes it easier to "prove" the benefit of the approach to a manager by showing him the generated lines of code.

    >
    > I think that the reason is that the output from the transformations is meant to run in current deployment environments.

    well, then give me a framework library with nicely abstracted interfaces to look at - in fact thats what I was referering to as a "VM". Masses of generated source code are certainly one of the last things I like to look at. If there is stuff you can generate - i.e. you know the contents in advance, then IMO there should be nothing to keep you from wrapping that into a higher level library.
  11. whats the benefit of code generation[ Go to top ]

    I have always why MDA emphasizes generating code so much. If they really have a new way of modelling and specifying all relevant aspects of a system, then they should give me a virtual machine that is able to run the spec as is, instead of throwing out pages of (cryptic) code that has to be run through a compiler and all. My suspicion is that the reason is simply that it makes it easier to "prove" the benefit of the approach to a manager by showing him the generated lines of code.


    You are correctly seeing through the salesman's silver bullet patter.

    If, on the other hand, you simply regard MDA as a different way of *coding*, then it is simultaneously less threatening, less magic, more approachable, more tangible, and (for the right problem) more useful and usable.

    But the salesman and their customers (i.e. managers) don't like that :)
  12. whats the benefit of code generation[ Go to top ]

    I agree. Good generation process is a waste of time. I am a big believer in Declarative Programming Model (DPM). Can some explain the difference between MDA and DPM?
  13. whats the benefit of code generation[ Go to top ]

    oops! I mean *Code* generation is such as a waste of time.
  14. whats the benefit of code generation[ Go to top ]

    Good generation process is a waste of time. I am a big believer in Declarative Programming Model (DPM). Can some explain the difference between MDA and DPM?

    There really isn't a difference, so it's a false dichotomy. For example with Apache's XSLTC I can generate procedural code from a declarative language. Conversely XMI could in theory be interpreted at runtime without generating code, and this may eventually happen in the industry. Code generation might be a bad design smell, but MDA needn't rely on code generation.
  15. Code generation vs virtual machine[ Go to top ]

    ... they should give me a virtual machine that is able to run the spec as is, instead of throwing out pages of (cryptic) code that has to be run through a compiler and all.


    Aren't these isomorphic? Certainly they're made isomorphic by a good optimizing VM. Consider Sun's Java virtual machine, that converts on the fly between bytecode and machine code as hot spots are identified (convert to machine) or new subclasses are loaded (drop back to bytecode).

    It could however be argued that the codegen process could be made more transparent, if the cryptic code is bugging you ...
  16. Read the point-counterpoint articles in the IEEE Software magazine.

    http://www.agilemodeling.com/shared/mda.pdf

    It mentions other reasons why MDA is good or not good.

    Thanks
    M
  17. Of Architects and "coders"[ Go to top ]

    Christopher Alexander (in "The Timeless Way of Building") clearly understands and explains the consequences when society split the roles of "builder" and "designer" to create "Architects". Of course in "The Timeless Way" he is referring to physical buildings, towns, and cities. But, in my experience his thesis holds true in systems development. The best "architects" (IMHO) are also "master coders" and always "keep their hands dirty" with the business of coding. I can personally attest to this as being one who for a few years was given the title of "Architect" - which of course (in management's infinite wisdom) meant I was too valuable to wasting my time coding. Having come full circle, I still "architect" sytems - but I'm also part of the team that implements. I find each activity complements the other and I'm better at both as a result.

    "God is in the details"

     - Ron
  18. The only use I can see for MDA is very narrow indeed. It must target specific frameworks and offer developers very little freedom of choice; otherwise, the transformations become incredibly complex and difficult to maintain. Even so, there are still other dangers lurking in the land of MDA.

    On a more serious note, this strange separation between architect and developer has got to stop. Architects who do not take part in implementing what they specify quickly become out of touch with reality and underlying implementation platforms. Likewise, developers who don't have a firm grasp of OO principles (as well as new paradigms such as AOP) are equally useless. I think this quote from Christopher Alexander is appropriate here:

    In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either.

    Here is how I would rewrite it for this situation:

    In fact, people who study and specify architectures without also practicing design and implementation are almost always frustrated developers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either.
  19. Martin Fowler has an interesting piece on the role of an Architect that strikes a balance in the otherwise polarized view of architect v. developer.
  20. Generals v/s soldiers[ Go to top ]

    A true General is a soldier who has risen through the ranks. Only if the General has fought many battles (and won them), can he plan for a war.
  21. Martin Fowler has similar reservations about MDA. Recently he talked about it in his blog. Look this up:
    http://www.martinfowler.com/bliki/PlatformIndependentMalapropism.html

    --Dilip
  22. Martin Fowler has similar reservations about MDA.


    Martin is an authority, but not everything he says makes sense.

    Now, MDA is not the answer but the underlying concept is. Currently, however, MOF and UML (even with action semantics) is insufficient, but we're on the right track.

    I see a lot of confusion about MDA beeing the new CASE. This is far from the truth, because an MDA tool can map to whatever tool, language or technology - it is not a proprietary technology as the CASE tools were.
  23. Warmed Over CASE[ Go to top ]

    Sigh, I was involved in the CASE industry in the late '80s. All the same claims were made for CASE that are being made for MDA. The CASE vendors didn't deliver on those claims in any tangible way and the industry cratered. Maybe I'm just old and cranky but I seriously doubt if the MDA advocates will fare any better.

    I've always claimed that one of the reasons we in the CASE industry couldn't deliver on our promises was that our diagramatic notations lacked the necessary semantic precision to create executable models. With the exception of the StateChart component of UML I think that's still the case (no pun intended). Even if it were otherwise it's never been clear to me that creating and/or decyphering a diagram is *that* much simpler than reading well written code. Yes, there's no end of poorly written code in the world but don't think for a minute that the same won't be true of diagrams/models.

    It seems there is a group of people in the world who want desparately to be more than "humble programmers". That title, however, was good enough for Dijkstra and so it suits me fine - now if I could just rise to Dijkstra's level intellectually!
  24. Warmed Over CASE[ Go to top ]

    Sigh, I was involved in the CASE industry in the late '80s. All the same claims were made for CASE that are being made for MDA. The CASE vendors didn't deliver on those claims in any tangible way and the industry cratered. Maybe I'm just old and cranky but I seriously doubt if the MDA advocates will fare any better.


    IMHO the MDA advocates have a better chance because they have started with a sound theoretical base: static data relationships expressed in class diagrams, plus dynamic behaviour expressed in (a subset of) Harel StateCharts and an action semantics language. Which seques into your next point...


    > I've always claimed that one of the reasons we in the CASE industry couldn't deliver on our promises was that our diagramatic notations lacked the necessary semantic precision to create executable models. With the exception of the StateChart component of UML I think that's still the case (no pun intended). Even if it were otherwise it's never been clear to me that creating and/or decyphering a diagram is *that* much simpler than reading well written code. Yes, there's no end of poorly written code in the world but don't think for a minute that the same won't be true of diagrams/models.

    It *is* true for some types of problem, notably those that are cleany expressed in FSMs, which by happy chance is at the core of MDA. Of course, if your solution is not easily expressed in FSMs, then MDA won't help. Screws vs nails.

    But FSMs are appropriate for many problems related to distributed cooperating systems. However, most serverside programming frameworks attempt to hide those issues from the typical programmer.


    > It seems there is a group of people in the world who want desparately to be more than "humble programmers". That title, however, was good enough for Dijkstra and so it suits me fine - now if I could just rise to Dijkstra's level intellectually!

    The split between "architect" "designer" "programmer" is, IMHO, false and damaging.
  25. What MDA can do for me[ Go to top ]

    I believe there is little doubt that the MDA concept will trouble our minds and conversations for quite a while. MDA may also mean different things to different people.

    I like diagrams no matter what. A picture can capture so many lines of code for me while trying to understand or communicate it. So I welcome pictures as long as they are effective and clear and also known to my piers. It is a language which many books are ready to shed light on because I am tired of explaining the same concepts to new co-workers all over again. That part of the MDA is good for me. I also appreciate writing less repetitive code. That part of programming that I've already done so many times and lost its creative nature. It's captured in many API's isn't it. So here's again another part of the MDA that I welcome. If XDoclet users reject MDA they use code generators all the time.

    The problem with MDA tools is that they try to do too much and are many times designed by the wrong people. Yeah, not the ones in the trenches. I found MDE from Metanology most suitable for me although it falls short in many places. (I am not affiliated with them in any way). MDE has what it calls 'metaprograms', which is code that controls how code is generated. Concept familiar to many open source tools, isn't it. Much like XDoclet, but with a GUI (Model) interface. Now, anyone against MDA, what is wrong with this? Such a tool is for the developer or architect alike. Your skill and creativity goes into that metaprogram so most likely, you only do the menial task just once. As a developer, that is exactly what I want in a MDA. Can MDA do that for me? And I don't need all those diagrams. A class, sequence and statechart should suffice. Reverse code. Don't step on mine. It's so amazing how tool vendors just don't listen.

    That's what MDA can do for me. I am actually hopeful about MDA and I care less about the philosophical aspects of it while I am very interested in writing good code.

    IMHO
  26. rickard writes:
    "To me this is a fucked up view of reality. It is encouraging a mentality that I believe is elitistic and contrary to the spirit of both OpenSource and XP programming"

    Well, this says it all, doesn't it? Everything not "OpenSource and XP" is BAD, BAD, BAD! I think it's rickard who has a fucked up view of reality; far from all projects can be done the XP way, just as far from all projects can be done the MDA way.

    "(Note to self: I wonder how many MDA tools are implemented using MDA)."

    OK - so this only shows that rickard really doesn't understand the scope of MDA. MDA is meant to help solve domain-specific development problems, nobody said it was a panecea. Well... somebody have probably said that, but OMG is not one of them.

    Example: creating a DICOM (a healthcare standard) server on any platforms is now reduced to creating a mapping to that platform and create a ditto generator. We've done it and it works. Effect? It took us 4 days to write the generator (which read an XML variant of the MDA mapping) and it spittet out ~180 000 lines of bug-free Java/SQL92/Script code. And the nice thing is that the code is so good that anyone could easily start working on it manually (not that we needed to). It's not spaghetti.

    But MDA is only as good as the mapping specification. For a lot of industry specific applications, MDA will reduce development costs dramatically. But it is meaningless to apply MDA to, say, a modelling tool or a compiler. Get real, man!

    "The assumptions are that a) it is possible to create models that capture the requirements of the application and b) these models are better than writing code."

    rickard doesn't get the whole picture, now does he?
  27. CIM[ Go to top ]

    My team is having success transforming DMTF's CIM MOF to java code. One of the primary advantages of using their model is that we can leverage all domain thinking that has gone into the development of this model. At 900+ classes there are a lot of decisions that have been made.

    As for the Arch/Developer split, we don't have that problem.
  28. Rickard's article is ( apparently ) written from the perspective of an application developer that's done little or no enterprise level development.

    To make a simple analogy, would I want to hand-code 500 EJB beans if I can import a database schema and generate 80% of the code? So why on earth would I want to hand-code low-level java code if I can design an application from a higher perspective and generate most of the code?

    I don't use currently use MDA, but the value is clear to me as I've worked in enterprise development for several years. There's only a certain scale that a software development team/project can work to, and that scale is determined by tools, domain knowledge and team size.

    Grow the team to increase project scale and you get bit by Brooke's Law. Demand more specialized domain knowledge and your scale shrinks. Keep team size and knowledge constant and increase goals? You increase development time at an even faster rate. So most IT projects were created at a certain scale to meet certain minimum goals. In large organizations, these projects are glued together in haphazard and unpredictable ways to span the full range of the organization.

    If I can keep team size and necessary domain knowledge constant, but expand the scope of my toolset, I can expand the scale that I design the application for. Expand the scale high enough, and you can merge 8 or 10 existing applications into 4 or 5, eliminating strange transformations and adhoc integration points.

    Simpy re-writing the same code with the same team size at the same tool scale doesn't buy me very much in a large organization.
  29. Rickard's article is ( apparently ) written from the perspective of an

    > application developer that's done little or no enterprise level development.
    >
    > To make a simple analogy, would I want to hand-code 500 EJB beans if I can
    > import a database schema and generate 80% of the code? So why on earth would I
    > want to hand-code low-level java code if I can design an application from a
    > higher perspective and generate most of the code?

    You're right, you wouldn't want to do that, which is why I created the EJBDoclet project (now known as XDoclet) to deal with that problem.
  30. rickard writes:
    "To me this is a fucked up view of reality. It is encouraging a mentality that I believe is elitistic and contrary to the spirit of both OpenSource and XP programming"


    Rickard doesn't even realize that XP and MDA are complimentary.


    "(Note to self: I wonder how many MDA tools are implemented using MDA)."

    I've heard of at least one MDA tool that eats its own dog food. Rickard is out in the weeds.


    rickard doesn't get the whole picture, now does he?

    Rickard's blog entry was mostly FUD.
  31. Rickard doesn't even realize that XP and MDA are complimentary.


    You didn't read my blog entry, did you?

    > "(Note to self: I wonder how many MDA tools are implemented using MDA)."
    >
    > I've heard of at least one MDA tool that eats its own dog food.

    Which one? (note that I never said there weren't any, I was just curious if there indeed were any)

    > rickard doesn't get the whole picture, now does he?
    >
    > Rickard's blog entry was mostly FUD.

    Fair enough, show me a couple of examples. What were the FUD statements, and what was wrong with them? Let's get all of this straightened out.
  32. frameowork for writing code[ Go to top ]

    MDA isn't code. It's a framework for generating code from a specification. That's completely different. If you can fine a code generator that matches what you need then good for you. That would not be common. But a project can take the description and generate code directly targeted to their application. The leverage here is enormous.

    The backend code generation does become a sort of VM, but it's not static. The mappings are made by developers for their situation.

    From a previous post:

    The point of MDA for me is to have a way for developers
    to specify what and not how. The how is the architecture.
    Once the how is encoded, XP not withstanding, it's brutal
    to change in a large product. The architecture is largely
    project specific. I don't think using someone elses code
    will work most of the time. The expertise is developing
    the architectural components that express the higher level
    description.

    If i can i want to send this message to this client with this
    degree of reliability that's all i need to say. The implementation
    should does not need to be coded by a developer. There are opportunities
    of this type all over this place. The MDA is not code. It's not
    another implementation language.

    MDA is the thought the programmer has before the code gets written.
    It's i want to do X. The details of doing X may be simple or very
    complex, but it starts with an intent, a plan, a decision. Capturing
    details at that level is a big win. We can code the implementation
    of those details separately.

    I don't think representing the same thing in code is as powerful
    because the power is in the mapping between the model and the environment.
    The mapping is where the decisions are made, this is where the code is.
    If you remove the intelligence in this mapping you are stuck with static
    relationships that aren't changeable without programmer driven refactoring.
  33. frameowork for writing code[ Go to top ]

    Double Thoff - perhaps you didn't notice, the entire reason for software developers in the cosmos is to do "the how". Without a "how", you are not doing software development.

        - Mike
  34. Confusion about software architecture[ Go to top ]

    There seems to be a lot of confusion out there about the nature of software architecture (surprisingly, even Martin Fowler seemed to have missed the point).

    This confusion stems from the fact that software is a strange beast that has a dual nature: it is at the same time a product that expresses the intent, as well as the implementation details. These two aspects tend to be intermixed in people's heads all the time.

    The most important thing to realize about software is that it is basically just a <em>bunch of ideas</em>. Now, the actual fact that these ideas get to be materialized using the computing infrastructure tends to cloud this fundamental truism that all throughout building and using software products, we're basically dealing with ideas, nothing more. If we could somehow run those ideas using a more familiar, more common sense platform (such as a bunch of low skill human workers), the whole endeavor would stand less of a chance of being mystified and misunderstood.

    Now, ideas are nothing more than concepts, or mental representations. The significant part of realizing this is that our lives are also based on a bunch of mental representations. When I get up and go to work, I am entirely guided by my own set of mental representations. I have a more-or-less idealized picture describing what my work is all about (for instance, I know that I must arrive there before 9:00 am; but even this idea of 9:00 am is nothing but a mental representation of something as abstract as the passage of time). Same holds true for my coworkers. When the receptionist at my office receives an incoming call, and replies with a stock greeting, and then dispatches the call to the appropriate department/person, she is guided by her mental representations, telling her what her work duties are all about.

    The real role of software products is to tap into some of those mental representations, to model them, and to simplify them for the end users. If a software product ignores these mental representations, it will most likely be regarded as the utter failure by its end users. Consequently, it will be doomed to become a shelfware, or a dumpware (e.g. if a payroll application does not successfully tap into the mental representations shared by the employees of a typical payroll department, such application will not be used, at least not willingly).

    The role of software architect is to identify which of these mental representations make a difference in the sense of improving the business functioning/competitiveness. There will be many different mental representations vying for the architect's attention in any business situation. Most of them will be more or less irrelevant, in other words, either won't make a noticeable difference to the competitive functioning of the business, or may even deteriorate business functioning, if implemented.

    Software architect is a person who specializes in preparing the groundwork that will enable software developers to deliver solutions that will support the working of the relevant and important mental representations. This person is responsible for ensuring that software products implemented by the IT department serve the final goals of the business operations. If the solutions that the IT department delivers do not serve those needs, such solutions are not only wasteful, but could be right down harmful. The only reason we have software architects employed by the businesses is so that those costly misunderstandings wouldn't happen in the first place.

    Left to their own devices, software developers in general show the propensity for implementing ingenious solutions that may or may not have direct bearing on the success of the business venture. Such state of affairs is not tolerable by the successful businesses, who tend to deem such propensity as being a huge liability. Rather than investing resources into forming the software development group and hoping that these experts will somehow stumble upon a solution that will increase the competitiveness of the business operations, the stakeholders prefer to take the calculated risk by hiring an expert (i.e. a 'software architect') who will focus solely on ensuring that all the software development activities within the organization are employed only in order to increase the bottom line competitiveness of the business operations.

    The division of labor, thus, falls as follows:

    1. The stakeholders are responsible for the "why" portion of the business operations (why are we selling these type of products/services as opposed to something else?, etc.)

    2. Software architect, along with other mid-level management, is responsible for the "what" portion of the business operations (what do we need to do in order to increase the effectiveness of the business, as operated by the human users/mechanical and electronic devices?)

    3. Software development team is responsible for the "how" portion of the business operations (how are we going to implement the intentions identified and formulated by the software architect?)

    As you can see, software architect may not have to concern herself with the underlying computing infrastructure. She operates in the world of intentions (i.e. concepts, ideas). She needs to catalog, analyze and promote those mental representations of the business operations that increase the likelihood of improving the competitiveness of these operations. Once those mental representations have been singled out, the architect prescribes a solution that will support the workings of those crucial representations, thus eliminating the 'deadwood', or the less critical factors in the success of the business.

    The material provided by the software architect serves as a guideline for the software development team. Ideally, it takes the guesswork out of the task of developing software. It is the sole responsibility of the software architect to identify the most critical aspects of the mental representations utilized by the software development team. The architect then taps into the wealth of those shared mental representations, and paints a picture that will be plainly understandable by most, if not all the members of the software development team.

    Once that has been articulated, everyone on the team shares the same, or very similar, constellation of mental representations relating to what the final software product that they are building will look like, and what will it be able to do. The final product is always described in terms of goals, not features. Once completed, the final product should be able to support stated end users' goals. This approach helps streamline developers' efforts, as it dismisses altogether with the vague and/or erroneous specification details.

    It is obvious from the above that software architect must posses both the expertise in understanding the end users' goals, as expressed by their mental representations, as well as the software developer's mental representations. Software architect is the middle ground person, where the world of business and the world of technology meet. As such, this role is of utmost importance for today's businesses. Businesses that don't understand this, or that underestimate and undervalue the importance of such a middle ground person, are doomed to limp in the marketplace by trial-and-error, until a more keen competition eventually eliminates them from the marketplace.

    Alex
  35. Confusion about software architecture[ Go to top ]

    Very nice, Alex B. Unfortunately, I've only met two classes of "Software Architect":

       A) The one who can't code worth a damn
       B) The ones who forced to accept the title, and do everything in their power to live it down.

    The Type A's, of course, out number the Type B's by approximately 37 orders of magnitude.

    For the rare Type B's out there (all 4 of them), they will impale themselves through an eye with an ice pick before submitting to write a transformation as described in MDA.

    Leaving that part aside for a moment, you're also assuming for too much omniscience on the part of the "architect". They cannot have enough foreknowledge of an application to divine even the majority of the programming intents and problems that will arise. And the solution of having the architect tinker with the transactions as problems arise is a no-win situation too - the architect has just become the world's biggest bottleneck.

    I hear what you're saying about ideas and mental concepts, but so far the best way developers have learned to get it into bits is through an OO _language_. A really good developer (or one of the four type B architects in the world) can already create a framework or library that abstracts out the architecture. And the worms-eye developer can use that, or tweak it, or choose to work around it, or ignore it completely. This isn't optimal, but it's been proven to be the most workable solution around.

    The reason why is two fold:

       - Linguistic-based expression has been proven to be the most capable of
         describing solutions to software problems. A picture may be worth a
         thousand words, but the problem is each viewer seems to pick his own
         batch of words. Pictures are expressive, but ambiguous. Words are
         less so. The models and transforms you describe suffer the same problem -
         they can invoke powerful mental symbols, they in many people they'll
         be the wrong ones.

       - Distributed effort, Darwinianism, the power of choice, injection of
         controlled chaos - these have been proven to lead to the most robust
         sytems over the long term. Try to constrain one of those, and you're
         strangling the most vital part of software development.

    Perhaps MDA works for extra-super-rigid domains that have requirements acid-etched into titanium steel. And where the target "container" has occified
    into infinite rigidity. For day to day programming, though, it's CASE all over again, but with an annoying software architect thrown in to make things even more frustrating.

       -Mike
  36. Confusion about software architecture[ Go to top ]

    I absolutely agree with you, Mike. Still, no one seems to realize (or, no one seems to bother to express the realization) that MDA is strictly concerned with the implementation. It's in the "how" domain. Software architect operates in the "what" domain. It's as simple as that.

    When it comes to the "how" domain (i.e. the implementation domain), we can argue till we're blue in face which approach to use. Many, many approaches are possible. Each organization must find its own, tailored approach. That tailoring will be governed by various extraneous and internal constraining factors, such as the existing expertise level inside the organization, the cost of upgrading/hiring the expertise level, and on and on. There is no formula for solving that type of a problem.

    However, when it comes to addressing the "what" aspect of software development, choices get to be much narrower. Basically, the primordial question is "what do we need to build/purchase/integrate in order to enhance the existing level of efficiency/competitiveness?" This is where software architect must step in and prescribe the solution.

    It absolutely doesn't matter *how* will thus prescribed solution be implemented, so long as it gets implemented in time and on budget. That's all the stakeholders care for. It also absolutely doesn't matter how will future changes to the adopted solution be handled, so long as they get to be handled in time and on budget.

    The architect may or may not be concerned about providing a platform for implementing the prescribed solution. He may choose to go with the open systems, open source solution, or with a single vendor solution (e.g. Microsoft, Oracle...), or he may leave that decision to software designers/project managers. Same holds true for the MDA approach. But he must provide the guiding light that clearly points to the sharply delineated product that must be delivered. The onus is on the architect to ensure that no superfluous development will ever occur. And the only way to insure that is if he communicated clearly and without any ambiguity the exact intentions when building the product. This can be only communicated effectivelly if the architect can think in terms similar to the way software developers think. That's why it only makes sense to hire an architect who had risen from the trenches of software developers.

    An architect who doesn't know how to code is akin to a writer who doesn't know the rules of grammar. It's a travesty to hire a person to play the role of a software architect if that person doesn't know how to build software products.

    Whether an architect chooses to use pictorial, or verbal means of expression is a non-issue as well. A good architect will choose expedient means at hand, that are tailored to the sensibilities of the software development team.

    The last thing an architect wants to see on a software development project is people debating whether to use CASE or scripting or UML or XML. That's merely a waste of time, and is largely irrelevant for the success or failure of the product. One's personal preferences are fine on one's own private time, but in the business environment, one is obliged to embrace whatever makes sense given the organizational constraints.

    The biggest problem with almost all software development situations I've participated in so far was the fact that no one knew exactly what we were building. Because of that, endless guesswork tended to emerge, and the real issues tended to get clouded by the fake ones (such as do we use this or that methodology). An architect has one central role -- to make sure that this confusion never raises its ugly head. Everything else is secondary.

    Alex
  37. Confusion about success[ Go to top ]

    /* An architect has one central role -- to make sure that this confusion never raises its ugly head. Everything else is secondary. */

    Hmm. I have worked on good teams before where each person was an expert of their domain and a great synergy develops in peer roles as well as more satisfaction. I would encourage debate because that is how better ideas surface. An architect has no monopoly on good ideas and I dare say MDA tools may hinder some good ideas and competitive advantage.

    Someone said that VB could easily generate 95% of the solution leaving the last 5% as impossible while C++/Java got you 80% of the way there with the last 20% at least doable. MDA may fit this pattern.
  38. Confusion about success[ Go to top ]

    /* An architect has one central role -- to make sure that this confusion never raises its ugly head. Everything else is secondary. */

    >
    > Hmm. I have worked on good teams before where each person was an expert of their domain and a great synergy develops in peer roles as well as more satisfaction. I would encourage debate because that is how better ideas surface. An architect has no monopoly on good ideas and I dare say MDA tools may hinder some good ideas and competitive advantage.
    >
    > Someone said that VB could easily generate 95% of the solution leaving the last 5% as impossible while C++/Java got you 80% of the way there with the last 20% at least doable. MDA may fit this pattern.

    Not only does an architect not have a monopoly on good ideas, he is not even expected to provide any good ideas when it comes to implementation. That is not his job.

    Usually, the team itself is expected to sort out the dilemmas related to the combination of technologies to use when implementing a product. That happens either through team synergy (as you've noted), or through a series of decisions made by the lead designers/project managers. Again, architect should have no say in these matters.

    One thing that seems to be hard to get through to software developers in general is that MDA is an implementational technology, and that architects should not be involved in encouraging or discouraging it. Whatever the team feels is the best tool for the job at hand should be the final arbiter.

    When I mentioned that an architect must ensure that the confusion does not arise, I was referring to the confusion related to not knowing precisely WHAT is it we're building, not HOW are we to build it. Again, the architect does not have to have any input into the HOW part of the equation.

    The development team has no time, nor expertise (nor interest, frankly) to go out and try to grasp the mental representations of the end users who will be using the software product. Developers have their hands more than full with trying to satisfy the demands of the underlying computing infrastructure. This infrastructure is actually very demanding, as it keeps growing in complexity, and therefore it demands full time attention of a team of highly skilled technologists. Thus, the technologists (i.e. developers etc.) really never stop to even think if serving the needs and goals of the end user is important or not. That's the responsibility of an architect.

    Just because the technologists couldn't care less about serving the needs of the end users, doesn't automatically mean that those needs are irrelevant. On the contrary, they are much more important than the needs of the underlying technology. The underlying technology exists to serve the needs of the end users, not the other way around. Technologies such as MDA have absolutely no bearing on this fact. Nowhere in the MDA approach do we see anyone mentioning the need for supporting the goals of the end users/business operations. This is because MDA is strictly concerned with implementation.

    So, whether an organization chooses to implement their system using assembler, or using MDA, makes absolutely no difference. It's similar to the need to deliver parcels from company A to company B. The parcels need to be delivered, but how are they to be delivered is largely irrelevant. They could be delivered by sending couriers on foot, or giving them bicycles to pedal there, or giving them cars, or trucks, or sending them on the trains, or planes, or ships. The important part is that those parcels get delivered to their destination on time.

    Same is with software products. All we need to see is those products being implemented, according to the specifications, on time (and within budgetary constraints). How they get to be implemented is opaque, from the stakeholders' viewpoint.

    The architect need not concern himself with technology. He can safely use paper and pencil when formulating the requirements and specifications. But he needs to understand very closely the way typical developer's mind works. Understanding this, the architect can articulate the specification in a way that supports developers' mental representations of their work-related domain.

    Finally, as far as the 95% completion as opposed to 5% not completed, vs 80% as opposed to 20% doable comparison goes, this reveals typical mindset of an honest to god technologist. It is symptomatic of our industry that most people don't realize the difference between possible and probable things. In general, technologists seem to be focused on the possible -- when tackling a problem, technologists invest considerable effort to cover all the possibilities that might happen. Pragmatists, on the other hand, tend to largely ignore examining all the possibilities, and focus instead on probabilities -- what in the given problem domain is very likely to happen? Of course, anything's possible. But, do we really need to pour over any remote possibility? How do we code our application to handle the exception of a meteorite hitting the service center?

    So, the remaining 5% of the implementation that was left impossible to implement, how likely is that 5% to ever occur?

    Alex
  39. Confusion about success[ Go to top ]

    Ah, now I understand. In practice, on practical large projects involving many different people in different roles, I have encountered the sort of Architect you are describing.

    This is the archetype of the Type A Architect - the purest of pure of the breed. As per your description, this individual produces copious amounts of output, and talks alot - but produces absolutely, positively, without a doubt nothing of value. Zip, zero nada. The advantage of the pure Type A is that they don't get in the developer's way - they just smile and nod when they get handed the 750 page specification/use-case/logical business domain diagrams, use 'em to heat their homes, and then talk to the real people doing real work to find out what needs to be done.

    The downside, of course, of the Type A archetype is that they typically go for 4 times the rate of regular software developers, and can easily bankrupt a projects (or just encourage endless shouting matches with the client). They are usually quietly removed without fanfare once the client and managers figure out just how useless they are - at which point they roll onto the next project which has room for a $200/hr waste of oxygen.

    There is room in projects for good project managers (_real_ project managers!), for business analysts with domain expertise (_real_ business analysts), tech writers and QA people and other support staff, and tech leads and other development staff. These are useful rolls. The role you have described is the purest piece of fluff that ever was.

    You didn't mention it, but this Architect probably uses every single artifact of the Rational Process, is incapable of using less than 3 buzzwords per sentence, and has the ability to stun real developers at 200 yards with a single phrase.

        -Mike
  40. Confusion about success[ Go to top ]

    As per your description, this individual produces copious amounts of output,

    >and talks alot - but produces absolutely, positively, without a doubt nothing
    >of value. Zip, zero nada. The advantage of the pure Type A is that they don't >get in the developer's way - they just smile and nod when they get handed the
    >750 page specification/use-case/logical business domain diagrams, use 'em to
    >heat their homes, and then talk to the real people doing real work to find out
    >what needs to be done.

    In other words, you seem to be adamantly against any kind of strategist on a project. This would be similar to waging a war without a general. What is a general good for, anyway? He just sits in his tent, far away from the front line, and produces nothing of value (other than copious amounts some strategic diagrams). Although a general does not get in soldier's way, he doesn't contribute anything worthwhile anyway.

    I have encountered the sort of developers harbouring sentiments that resemble yours. These are the people who fancy themselves being the sole keepers of the most vital business knowledge. They look at any high-level strategists with unbridled suspicion, because how can these architects know anything, if they are not getting their hands dirty digging the trenches? In addition, the developer's mighty pissed because the high-level strategists are threatening to take his exalted status away, by divorcing the knowledge of what needs to be done from the knowledge of how to do it.

    By denigrating software architects the way you did here, you have given us the worst case scenario. I'd like to examine now the ramifications of this worst case scenario and compare them to the ramifications of what usually transpires on many software projects:

    Suppose you're right, that is, suppose that the architect contributes absolutely nothing of value to the project. Suppose that she is employed there strictly for ritualistic reasons, as a high priestess who merely administers several buzzwords to the unwashed masses of developers.

    The question is -- what harm has been done by doing this? Other than a slight overhead in the expenses (and trust me, $200.00 per hour is unheard of; it's more in the vicinity of $60.00 to $85.00 per hour), this worst case scenario situation is largely harmless. As you've already said, the architect is absolutely not in the developers' way, she is substantially detached from the implementation trivia.

    Compare the above hypothetical situation with a very realistic situation of having gung-ho know-it-all developers running amok during the project. They shoot from the hip, they don't wait for the gun smoke to clear, they charge ahead oblivious to any issues surrounding the project. I've seen countless of such yahoos (code jockeys, which is a nice euphemism for hackers), wrecking catastrophical damage to the project. Yes, their hourly rate may be cheaper than the architect's (although not necessarily, I've seen some of those hackers charging $120.00 per hour for their 'guru' services). But the amount of damage these morons are capable of incurring surpasses by far anything that an architect could ever dream of incurring.

    In reality, however, the worst case scenario that you've described actually never happens. Yes, there are phony architects, same as there are phony developers (and phony physicians, and phony lawyers, etc.), but in general, architects are highly experienced, highly skilled individuals who can make huge improvements to the product.

    You are free to choose to close your eyes before this fact, but you're doing it at your own peril.

    Alex
  41. Confusion about success[ Go to top ]

    This is the archetype of the Type A Architect - the purest of pure of the breed. As per your description, this individual produces copious amounts of output, and talks alot - but produces absolutely, positively, without a doubt nothing of value.

    Totally, what a waste of brain power to be an architect who doesn't contribute content. I think we both agree that feature development is what really matters. A successful development pipeline should only have value adding steps -- those essential to preparing business features for delivery. MDA helps with this in a technical way.

    But the make-nothing architect is a symptom of traditional process, where the modeling tools and the coding tools aren't coupled in an automated pipeline. This leaves ample room for human parasitism. MDA is an obvious cure that I appreciate since it eliminates architecture as an in house chore. Bye bye make-nothing architects.
  42. I am the A type :)[ Go to top ]

    This is interesting! I seem to be type A. I have the title Systems Architect (fancy, ain't it) and work in multi-project environment. I am not a good programmer/developer. But I understand about systems design and 'architectures' (hopefully). AND I HATE RUP (although dX is an interesting implementation of RUP..) and have abandoned most of UML. To me the most interesting development methodology is Crystal Clear.

    What do I do? Ok, I help around in the projects. I don't (usually) code. I make decisions - when no one else wants to. Example: there is a design problem. I ask the developers what the options are. Then we possibly draw some (free-form) diagrams on the whiteboard or paper. Then WE find a decision. I try NOT to write a single document. I try NOT to interfere unless necessary.

    I challenge designs ("why do you want a component like this?"). I do technology prototyping and evaluations. I make mistakes :). I take part in project meetings and design sessions. I create stupid powerpoint presentations for management.

    I think my value for a single project is propably around 1% of the total. But I hope my value for the whole IT environment is bigger.

    The Tao of the Software Architect

    Peace and Love,

    Ras
  43. Confusion about software architecture[ Go to top ]

    That's why it only makes sense to hire an architect who had risen from the

    > trenches of software developers.

    Considering that software developers that use MDA are supposed to code through modeling, how are they to acquire skills required to become a good "architect" able to create MDA transformations?
  44. Confusion about software architecture[ Go to top ]

    Considering that software developers that use MDA are supposed to code

    > through modeling, how are they to acquire skills required to become a
    > good "architect" able to create MDA transformations?

    I think Rickard has hit the nail on the head here. At the moment there are enough good architect/developers who know how to pull together a wide range of standards, libraries, open source projects and APIs in order to provide something that business logic can be built on top of. If MDA becomes a success then this set of skills will reduce quite rapidly. What will be left? We will just have to use the default transformations provided by the MDA tool manufacturer? This can only be bad for open source and so on as MDA tool vendors are only going to target mass-market products and standards like EJB, WL, WS, Struts etc. where they feel they can generate an income.

    I'm personally quite intesteded in MDA because (in theory) I can pull together all the best-of-breed stuff that I use on a day-to-day basis, call this an architecture, define a transformation for it and reduce the amount of tedious skeleton business code that I have to write. If I'm forced down a route of running with an architecture that some tool vendor has come up with and which is possibly not 100% appropriate to the task in hand then for me the entire value proposition for MDA is lost.
  45. Confusion about software architecture[ Go to top ]

    This can only be bad for open source and so on as MDA tool vendors are only

    > going to target mass-market products and standards like EJB, WL, WS, Struts etc.
    > where they feel they can generate an income.

    Right, basically what you are doing is that at some point you say "this subset of reality is as good as it gets, so I'm going to use it to define my entire reality". In other words, the "silver bullet" syndrome. You then lock yourself into that reality, and while this may provide a certain sense of comfort, it also limits the possibilities for evolution and progression. This is why I "subtitled" my blog entry "into the twilight zone".

  46. > Right, basically what you are doing is that at some point you say "this subset of reality is as good as it gets, so I'm going to use it to define my entire reality". In other words, the "silver bullet" syndrome. You then lock yourself into that reality, and while this may provide a certain sense of comfort, it also limits the possibilities for evolution and progression. This is why I "subtitled" my blog entry "into the twilight zone".
    >

    Well, I'm still far from convinced on MDA, but I think this is a spurious argument... The idea would be that you have your models and you can change your code templates and generate WebWork2 instead of that Struts crap :-) without having to change your models.
  47. to MDA or not to MDA[ Go to top ]

    <chris>
    I think Rickard has hit the nail on the head here. At the moment there are enough good architect/developers who know how to pull together a wide range of standards, libraries, open source projects and APIs in order to provide something that business logic can be built on top of. If MDA becomes a success then this set of skills will reduce quite rapidly. What will be left? We will just have to use the default transformations provided by the MDA tool manufacturer? This can only be bad for open source and so on as MDA tool vendors are only going to target mass-market products and standards like EJB, WL, WS, Struts etc. where they feel they can generate an income.
    </chris>

    Well, who cares? If you can use MDA and produce code faster then why not? You shouldn't care if the knowledge of the developers community of the world would go away in the comming decades. As I've always said if you have something repetitive use code generation if you can.

    I think there are two facets to this discussion:
    - the technicalities of MDA and UML
    - and the MDA/architect oriented process vs programming oriented process

    As for the first item, I think so far we've seen two code generation schools of thought: those who use code generation (in form of XDoclet or AndroMDA) to produce "small and well defined pieces of code" to automate things and "prevent repetition", and those who want to program in a higher level lanaguage like UML and let it craft it (or most of it). I'll give you an analogy that I think perfectly applies here: robotics. The best robots and the ones that are in widespread use in industry today are simple ones, most one of them just have 1-2 arms and move in strictly defined directions. Scientists have tried to design more complex ones that do a lot more, but we're not yet there. I think small robots like XDoclet and AndroMDA are useful today, while complex robots like the MDA ideal are far away in the future. Maybe some day, but not today. "The design is in the code" and a textual piece of code is the best media we have to express a complex software, not a visual one like UML.

    As for the second item, it's really an XP versus heavyweight methods argument. There are architects in heavyweight ones, and there's the role of a couch in XP. They both deal with technical leadership but the approach is very different. Architects assume that developers are less-knowledged so they try to provide "just click click" solutions, I've thought for you, you don't. The XP approach on the other hand beleaves in communication and transfering knowledge among the team, by pairing, by the role of the couch, by simple design and so on. In the first approach knowledge is kept on the architects side, in the side one knowledge is spread among the team.

    Ara.
  48. to MDA or not to MDA[ Go to top ]

    I think so far we've seen two code generation schools of thought: those who use code generation (in form of XDoclet or AndroMDA) to produce "small and well defined pieces of code" to automate things and "prevent repetition", and those who want to program in a higher level lanaguage like UML and let it craft it (or most of it).

    The gap between these two approaches isn't as wide as you might think. And the gap is narrowing each year.
  49. Confusion about software architecture[ Go to top ]

    That's why it only makes sense to hire an architect who had risen from the

    > > trenches of software developers.
    >
    > Considering that software developers that use MDA are supposed to code through modeling, how are they to acquire skills required to become a good "architect" able to create MDA transformations?

    You're talking about some hypothetical, future software developers, right? I know of no such person at present time. Who codes through modeling? Even if there are such people, they have been out of necessity recruited from the ranks of regular coders. These people have been formally trained to think the way the entire industry thinks. So, when some of these people decide to upgrade their skills and become architects, they bring their ingrained coding skills to the table.

    Now, MDA is still a pie in the sky, and it is very likely that it will never become mainstream. I wouldn't fret too much about such probability. Even if it becomes mainstream, it will be embraced in a half-assed manner, as everything else does (even RDBMS systems, after thirty years of maturation, are being implemented half-assed today; how many organizations really take care to normalize to the 3rd normal form?) Not to mention OO, which is being used mostly as an excuse to continue doing the good old procedural coding.

    Alex
  50. Confusion about software architecture[ Go to top ]

    Alex B, good article.
    To all who are interested in this topic, please visit http://www.bredemeyer.com . It has very good information on this topic.

    IMHO, Architecture and Design are same things looking from different angles. Architecture is a view from outside where as design looks from inside. As Alex said, difference is "What" and "How". Architecture would specify the components and their general purpose towards system goals. Design should specify their interactions amongst each other. Architecture is more concerned about the environment and the message/purpose that it wants to give to outside parties. A design would assume an environment.

    I saw many views that say, "Architecture is not concerned about implementation". This is not true either. Architecture is responsible to convey concrete idea and it has to specify major components if not their interactions. To me, language/ database/ OS are those major components.

    I don't agree to view that "architecture is about the things that can not be changed later" or is a "concept in expert developers mind". To me it is much more than that.

    Architects are responsible for conceiving idea of the system, finding its applicability and profitability in business, expressing these ideas in terms of architecture, and selling it to customers, stakeholders, developers and others.

    Thanks,
     - Parag
  51. Confusion about software architecture[ Go to top ]

    There seems to be a lot of confusion out there about the nature of software architecture (surprisingly, even Martin Fowler seemed to have missed the point).

    Totally. Fowler and Rickard are stuck in the old school, a sort of purgatory for amanuenses.

    The most important thing to realize about software is that it is basically just a *bunch of ideas*. Now, the actual fact that these ideas get to be materialized using the computing infrastructure tends to cloud this fundamental truism that all throughout building and using software products, we're basically dealing with ideas, nothing more.

    Yes, the skeptics are distracted with tactics and blind to strategy.

    The real role of software products is to tap into some of those mental representations, to model them, and to simplify them for the end users.

    Amen. Requirements analysis is where developers matter most, not the implementation trivia.
  52. Confusion about software architecture[ Go to top ]

    \Brian Miller\
    Amen. Requirements analysis is where developers matter most, not the implementation trivia.
    \Brian Miller\

    Implementation trivia. That's great!

    "Hey, guys, listen up - everything you've been pouring your blood, sweat, and tears into for the past 5 months is implementation trivia! You know, all that 'code' stuff? Irrelevant minutiae! You should have been spending all your time doing Requirements Analaysis".

    "OK, Joe P. Architect - tell me how to execute that 57.2 Megabyte Word document of yours, and we're in business".

        -Mike
  53. Confusion about software architecture[ Go to top ]

    Are you talking to me?
    I have never written such a document, and--lord willing--I never will.

    -Joe P.
  54. Reminder[ Go to top ]

    I like to remind the particiapants on this thread that my blog entry does not focus on the technical viability of MDA, but on the view of developers it adopts. As such, to me personally all technical arguments that are used here are really missing the point.

    That is, if you are using this thread to discuss my blog entry on MDA, which you are of course entitely entitled to not do. This is, after all, TSS :-)
  55. Reminder[ Go to top ]

    "I like to remind the particiapants on this thread that my blog entry does not focus on the technical viability of MDA, but on the view of developers it adopts. As such, to me personally all technical arguments that are used here are really missing the point. "

    LIAR, LIAR, Rickard. You ask yourself in the blog whether or not it is possible to create an MDA tool using MDA. This is a question of technical feasibility. Nothing else.

    As for the "view of developers" - WTF is the problem? Developers would work on a higher level of abstraction - you may as well look at MDA as a development tool, methodology AND language. Again, MDA isn't mean to be a paneca - it's a thing for domain specific problems.
  56. Reminder[ Go to top ]

    LIAR, LIAR, Rickard. You ask yourself in the blog whether or not it is possible

    > to create an MDA tool using MDA. This is a question of technical feasibility.
    > Nothing else.

    I quote myself:
    "What disturbs me the most with MDA is not the "silver bullet" heraldry of it being the final solution to how we can now finally program using models, something which has been said before and never happened properly due to the complexities of round-robin modifications between models and code. No, what disturbs me the most is the view of reality that one must adopt in order to accept its, almost religious, promises."

    As I said, the *focus* of my blog entry is not on technical points. I didn't say there weren't any.

    > As for the "view of developers" - WTF is the problem?

    I again quote myself:
    "
    This is the scary part. Individuals are effectively pigeonholed based on their title ("architect" or "developer"), and there seems to be little incentive for individuals in the "developer" slot to learn more and work towards acquiring "architect" status. Why? Since all they are doing, with the wonders of MDA, is to create models which they use to build the applications. In other words, there does not seem to be any natural knowledge transfer, and teams will become even more hierarchically tied to the title one has acquired."
    and
    "
    This obviously lowers the demands on the knowledge that developers using MDA needs, and as such I have no doubt that it will become immensely popular in certain circles, and will no doubt help rationalize many developer organizations.
    "
    In other words, I'm not saying MDA is bad; I'm saying MDA is not for me. For organizations, and individuals, that value the traits I describe MDA will be a great thing.
    "

    > Again, MDA isn't mean to be a paneca - it's a thing for domain specific
    > problems

    In the articles, white papers and literature I have read to date this is never mentioned. Go figure. But maybe I just read the wrong articles. If you have references to better MDA articles, please feel free to post them here.
  57. Reminder[ Go to top ]

    I like to remind the particiapants on this thread that my blog entry does not focus on the technical viability of MDA, but on the view of developers it adopts.

    In most developers a high level language infixes a cavalier independence from operating machinery. Rickard and Fowler rely on an immense stack of abstractions that allow them to forget about bits and cycles. Such is the nature of any software production pipeline since the 1960s. So this sentiment that Rikard bemoans isn't new and predates MDA. Rickard is barking up the wrong tree, like a dog confused by a clever squirrel. He hopes so much his ossified praxis will matter tomorrow.
  58. Reminder[ Go to top ]

    I like to remind the particiapants on this thread that my blog entry does not focus on the technical viability of MDA, but on the view of developers it adopts.

    >
    > In most developers a high level language infixes a cavalier independence from
    > operating machinery. Rickard and Fowler rely on an immense stack of
    > abstractions that allow them to forget about bits and cycles.

    What is this "stack" you are talking about? Can you describe it? I wasn't aware that I was relying on an "immense stack of abstractions", but if I am I'd like to know about it.
  59. Reminder[ Go to top ]

    If MDA works they will come. Till then...

    The Captain said to John Henry
    'Gonna bring that steam drill 'round
    Gonna bring that steam drill out on the job
    Gonna whop that steel on down, Lord, Lord!
    Whop that steel on down.

    John Henry told his captain
    "A man ain't nothin' but a man
    But before I let your steam drill beat me down
    I'll die with a hammer in my hand, Lord, Lord!
    I'll die with a hammer in my hand."
  60. Reminder[ Go to top ]

    Oh my God - The Legend of John Henry on TSS!! Marvelous!

    "John Henry's Pappy Woke him up one midnight"
     He said 'fore the sheriff comes I wanna tell you....
     Learn to ball a jack, learn to lay a track, learn to pick and shovel too
     (and take my hammer boy)
     it'll do anything you tell it to."

    To massively mangle the words of the great and lamented Johnny Cash, don't get pigeonholed into one thing. Don't be a one hit wonder. And don't put all your eggs in a basket like MDA.

        -Mike
  61. Reminder[ Go to top ]

    And don't put all your eggs in a basket like MDA.


    Very true. MDA is lousy for some classes of problem; no surprises there! Coding fuzzy pattern matching operations or a regular expression acceptor directly in MDA would be relatively unproductive.

    My preference for a tool is one which is sufficiently powerful that the tool itself is (to a large extent) coded using itself (e.g. a compiler), but which lets you escape out of its rigid confines when necessary.
  62. an MDA story[ Go to top ]

    Rickard,

    did you ever try to actually use an MDA approach ? or did you just 'read up' on MDA ?

    I succesfully applied MDA using AndroMDA on two projects, of which one was a medium-sized PKI platform for a Certification Authority/TTP little more than 18 months ago. Development ran under ISO, so there were audits on software engineering (UML) as well as on implementation (Java EJB/Struts). This was for a leading security provider in Europe. At that time we were also going for a WebTrust accreditation, this is the root inclusing program from Microsoft.

    I had no MDA experience when I started that project, I learned as we progressed. We choose MDA after a short proof-of-concept which demonstrated we would actually gain something: time and money. As we progressed we had a project that was stable by construction, not unit testing, and that's a very comfortable feeling, I can assure you.

    We modeled using UML in a strict sense (meaning, not sloppy, but complete and accurate), at that time I thought I knew UML quite well, I was wrong... MDA helps you also to be a better modeler, a project benefits a lot from this.

    The 'transformation' has been done using VTL, we could change the content of the code generation templates at any point in time. Since most of the was generated the only thing left to do was the implementation of business logic and the layout of the JSP pages.

    Now the interesting part, we finished a rough version after 5 weeks !!! it was running, and we could show something to our management. Project deadline was still 4+ months ahead of us! This gave us time to think a little more about the architecture, to gather new/more requirements (iterative development) and to improve the overall look and feel (not to be neglected!)

    Mind you, we reworked an existing Coldfusion/OpenSSL platform into a J2EE platform, so we had already the domain expertise.

    Security in this area is 80% about policies and Service Level Agreements, 20% about technical stuff. This means that business requirements would change often (yeah, we had a very creative pre-sales team too), code RE-generation was no problem either as implementation code was never overwritten.

    so what software did we use ? we used the AndroMDA project on SourceForge.

    So when I hear all these negative things about MDA I have my doubts about the credibility of certain people on this thread. Don't forget you still need the brains to be creative and innovative, there's no such thing as waving a magic wand and having everything appear out of nowhere.

    I remember my grandfather telling my it's not a good idea to use a calculator, because I'd go dumb not being able to calculate something by heart.. you get the point.

    Just use what you feel most comfortable with, it works for me.

    best regards
    Wouter.
  63. an MDA story[ Go to top ]

    Dog - your story isn't very interesting (to me at least) because of the little bit buried in the middle of it:

       "Mind you, we reworked an existing Coldfusion/OpenSSL platform into a J2EE platform, so we had already the domain expertise".

         -Mike
  64. an MDA story[ Go to top ]

    Dog - your story isn't very interesting (to me at least) because of the little bit buried in the middle of it:
         "Mind you, we reworked an existing Coldfusion/OpenSSL platform into a J2EE platform, so we had already the domain expertise".


    Domain expertise is a prerequisite regardless of software development process, whether the he hacks code by hand or generates from models. The developer usually gains domain expertise through knowledge transfer from other folks, but how expertise is gotten is irrelevant. What matters is that the developer understands his application's requirements. The rest of production following requirements analysis is mostly routine derivation, even without automation. So a front loaded methodology has the greatest benefit.
  65. an MDA story[ Go to top ]

    \Brian Miller\
    Domain expertise is a prerequisite regardless of software development process, whether the he hacks code by hand or generates from models. The developer usually gains domain expertise through knowledge transfer from other folks, but how expertise is gotten is irrelevant. What matters is that the developer understands his application's requirements. The rest of production following requirements analysis is mostly routine derivation, even without automation. So a front loaded methodology has the greatest benefit.
    \Brian Miller\

    He wasn't talking about domain expertise - he was talking about taking a code base done in OpenSSL & ColdFusion and porting it to J2EE (presumably with some enhancements). This makes the job substantially easier - you've seen how the problem has been sovled in one way.

    As for your sentence:
     "The rest of production following requirements analysis is mostly routine derivation, even without automation. "

    If you think actual coding is "routine derivation", it leaves me with only three possible conclusions:

      - You've never coded
      - You've never coded anything substantial
      - You're not bending the truth - you're throwing it into a black hole and wrapping it into an incomprehensible singularity.

    Please - I'd love for you tell my boss that the work I do is nothing more than "routine derivation". I'll be sure to call the paramedics before hand to take care of his splitting his belly open from laughing so hard.

        -Mike
  66. an MDA story[ Go to top ]

    I'd love for you tell my boss that the work I do is nothing more than "routine derivation".

    If he felt otherwise, he'd still be a programmer. Of course he might have compelling reasons not to advertise this.

    As for me supposedly not being a hand coder:
    The Java grid code I manually slaved over was demoed at both Sun's and Stanford's booths at Super Computer 2002. I'll be showing it off at SC2003 again in a couple months. What I personally think mattered most was my understanding of the subject matter, and not so much that I can hack Java. The reason my name is last on the Computing in High Energy and Nuclear Physics conference paper is because I'm merely the grunt who gets to code the stuff. I dig coding it up, dude. I'm happily stuck in the trenches.

    Hand coding is extremely fun. But having done both hand code and model translation, I attest that diagramatic modeling is more fun than ad hoc hand coding. And with model translation the playful act of modeling is truly more productive than the ergonomic horror of hand scripting. The skeptics, such as yourself and Rickard, are the ones who likely haven't tried it *yet*.

    The nature of software development is changing. Job satisfaction necessarily gets a boost from techniques that reduce cognitive load. Analysts using MDA get to focus on some really cool stuff: their business domain's use cases and object model.
  67. an MDA story[ Go to top ]

    Please note that I didn't say you weren't a coder - I gave three alternative possibilities :-)

    As for your own experience, thanks for sharing more details. From what I've seen, it doesn't seem very applicable to what most people are talking about in this thread. What you've described is a highly technical project, with highly technical users, with yourself as the lone coder (please correct me if I'm wrong). That is a world plus 9/10ths away from the byzantine world of IT business software development.

        -Mike
  68. an MDA story[ Go to top ]

    hi Spille,

    we were not happy with the current application because of some critical security issues regarding the platform on which we were running, accreditation would nog have been granted unless we would port to another

    we used the existing platform as a basis for collecting the business requirements, all the technologies for the new project (except hardware) were built from the ground up, same goes for the architecture and design, we did not want to inherit any mistakes from the past. So basically we started from scratch, modeleing a completely different application, with the same features + a lot of extras

    that's what I meant with domain expertise, we did NOT port Coldfusion to J2EE ;-)

    is this what you meant ? or did I miss the point ?

    cheers
    Wouter.
  69. an MDA story[ Go to top ]

    we were not happy with the current application because of some critical security issues regarding the platform on which we were running, accreditation would nog have been granted unless we would port to another

    >

    re-reading my message, I saw I wrote the above... sorry .. we did not port, but completely switched from C -> J2EE
  70. an MDA story[ Go to top ]

    Sorry, I've done the same thing you have in different areas. Starting with an existing code base is a _huge_ leap forward from starting cold. You may not call it porting - but as I said, you've already seen one solution to the problem.

       -Mike
  71. I succesfully applied MDA using AndroMDA on two projects, of which one was a

    > medium-sized PKI platform for a Certification Authority/TTP little more than
    > 18 months ago.
    <snip>

    That's an interesting story, but you are making the same mistake as pretty much everyone else in this thread: you're thinking that my blog entry on MDA is about technology, and it really isn't. It's about software development tools as cultural tools, and the impact the mentality it assumes (or at least its most vocal proponents) can have.

    Again:
    My blog entry is not about technology. Most posters are replying as if it was. It's not. It is, I repeat, not about technology. It is about software tools as a cultural tool. Talking about MDA from a technological perspective is probably very interesting as well, but my blog entry is, I repeat, not talking about MDA from that perspective. As noted in the update of my blog entry on MDA as cultural tool you are of course free to ignore this for the purpose of discussing MDA as a cultural tool. This is, after all, TSS.

    The only conclusion I have drawn from this thread (and so many others like it) so far is that the majority of TSS posters are simply incapable of talking about MDA, or any development strategy/paradigm/technology, from any other perspective than the strictly technological one. And that's pretty much ok since this is, after all, TSS, and not a psychology forum. It is, however, slightly depressing.
  72. you didn't answer my simple question, I'll rephrase:

    I, Rickard Oberg have hands-on MDA experience (y/n) [n] ?
    %> _

    all those things you write in your blog about developers/architects etc... these are things you assume or expect, but are not necessarily true. IMO this is a matter of project management/company structure (whatever) not about MDA.

    and btw, you write it's not about technology... but that's you backing out, you talked about code generation and bullshit meters in the same phrase, so please

    signing off
    Wouter
  73. Personally, I dont care about the cultural aspects of MDA - because I believe that they are imaginary. Essentially, if MDA were actually able to deliver on its promises then, rather than cast "programmers" onto the scrapheap, it would allow the "programmers" to work on different stuff that is more interesting and that would deliver better value for money.

    Dont interprete this as a Rickard-flame - I see the same emotive knee-jerk reactions from some corporate C++ developers. "Well if Java is going to make my job simpler, then they wont need me any more - you are doing me out of a job :-o ". Wrong! What it means is that rather than wasting your valuable time with repetative bullshit, you actually get to develop something more interesting - and the business get better value for money. Its win-win.

    Ultimately, there is always a job for programmers. Software is usually developed to solve new problems (or at least should be). If a repetative problem can be abstracted away, it should be bought (e.g. middleware, persistance, etc). Programming, in one form or another, will always exist. Moving the coding to a higher level doesnt mean we need less programmers - it means we can do more.


    However, like many others, I dont believe that MDA IS going to deliver this pipe-dream that some pompous "new school" posters keep banging on about. It ignores a couple of those pesky little details about the real world:

    a) Stuff changes. MDA has a heavy dependancy on code generation, and its a technical fact that uni-directional code generation and evolving requirements dont mix well (except for when the generated code is a cross-cutting concern). The only time they fit well is when the code you are generating is a cross-cutting concern - hence the success of quasi-AOP EJB transaction/security/persistance interception code generation, RMI/CORBA stub generation - and even these examples can be achieved via non-generational means.
    The problem is that essentially none of the tools I have seen so far can handle round-tripping of code generation and changes in details very well. And if its not been successful so far, you have to ask yourself why that is. What has changed that now makes this possible?

    b) It assumes that the generated code is problem free (which wont happen if its changing a lot - ergo: good for cross-cutting concerns only). If you have to "code" from a very abstract model level (or transformation level) and then you have to debug at the very low level, then you are creating a nightmare. A simple one-line fix for some odd behaviour is suddenly very complex to fix.
    Now if it is one of the "mere minions" that has to debug this, they are not necessarily going to know how to fix it (because they dont understand it).
    At this point, your heavy abstraction now means you are trying to effect micro-code changes from such a high level of abstraction that its similar to trying to draw a picture with a paintbrush a the end of a pool queue.

    Then there is the question of whether generation makes sense.

    On this, I tend to agree with Christian Sell's post above - If there is a whole bunch of repetative stuff that you are doing - that is crying out for code generation - then its a smell. Refactor the repetition out! Why sweep in under the carpet via code generation?


    -Nick
  74. Role of the architect[ Go to top ]

    I think many people including Rickard misunderstand the role of an architect. An architect who gets his hands into code is not really an architect in my point of view.
    Lays an architect bricks? No. He designs the development plan and controls the work. I think he has to have good programming skills, so that he understands what is going on in the project and where the problems are, but he is more a leading personality than a "worker". This is the reason why many experts say that an architect must have at least 8 years of real development experience to become an architect.
    What is true, that in many projects the role "architect" is used to classify a good "developer" who is something like the framework developer or lead developer and makes designs stuff. So "normal" developers feel somehow lower qualified than architects. That is not true! Without good developers no project would be finished with success and the word architect for good developers is missused!
    I attended a REALLY good course about architecture and architects that is held by Dana Bredemeyer, an excellent architect. His homepage is great for architecture resources and comments on the role of an architect. See
    Bredemeyer.com for more information.

    Mirko, proud to be a developer.
    :wq
  75. Role of the architect[ Go to top ]

    I think many people including Rickard misunderstand the role of an architect.

    > An architect who gets his hands into code is not really an architect in my
    > point of view.
    > Lays an architect bricks? No. He designs the development plan and controls the
    > work. I think he has to have good programming skills, so that he understands
    > what is going on in the project and where the problems are, but he is more a
    > leading personality than a "worker".
    <snip>

    What you are describing is, effectively, an A type architect. Mike wrote thusly:
    > A) The one who can't code worth a damn
    > B) The ones who forced to accept the title, and do everything in their power
    > to live it down.

    See his post for more information about these two categories.
  76. Once more[ Go to top ]

    Yes, in Mikes world this is true, but in the consulting world this isn't.

    I am speaking of "real" projects were you have many different teams, different stakeholders and many different technologies involved. The architect has to keep the vision of the project in the minds of the developers and deignthe overall architecture. I am not talking about an UML modeller...this is developers stuff.

    In more technical driven projects (like building an AOP CMS from scratch) you and Mike are right, you don't need such an architect, because the technical part is most important and a developer genius like you can handle all the problems and build a working and cool application that in addition to that fullfills the "small" business requirements. In a "real" project e.g. building a internet banking system, such an approach would result in lost of millions of Euros...oh I forgot...millios of kronas :-)

    So I agree with you that in many cases we could better work without an architect if it is a developer that can't code and has no clue of what real software looks like. But in big projects an excellent architects worth gold!

    Mirko, still a proud developer.
    :wq
  77. Once more[ Go to top ]

    fullfills the "small" business requirements. In a "real" project e.g.

    > building a internet banking system, such an approach would result in lost of
    > millions of Euros...oh I forgot...millios of kronas :-)

    Perhaps you have some up-to-date statistics of the percentage of failed "real" projects that did NOT have an architect with excellent presentation skills and wonderfull visions painted in pretty pink .ppt? My guess is that 100% of them did, just like a 100% of the successfull ones did, making your point moot at best. All large-medioum scale client systems that I have been even remotely involved with have had an architect, and he/she was always quite adept at models. In reality his/hers work had a very minor impact on the outcome of the project. The real work is done in the trenches, and the biggest impact on the work in the trenches comes from the project manager who either manages to create an environment in which it is pleasant and rewarding to work - or not.

    IMHO.

    Br - J
  78. Once more[ Go to top ]

    I have worked in the consulting world, specifically on projects such as you describe. The Type A architects inevitably inject 100 pound documents that make no sense, play buzz-word bingo with the clients, and are astudiously avoided by the real development staff whenever possible.

    Indeed, the projects that succeed in these scenarios are the ones where there are smart developers who creatively ignore the architect's blasts of hot air.

    Mirko, I believe you are looking for an "architect", when in reality what you need are two seperate rolls - technical leads, and project managers (Good project managers!). Tech leads are real developers who also do high level design. Project Managers help the tech leads manage who does what.

    The problem with the architect role in software development is that little development details can rapidly snowball up into giant technical issues. We're
    not talking building construction here - real building architects can rely on bricks being a certain size and taking certain loads, the tensile strenght of steel, mountainous reams of building codes that standardize how low level activities are performed.

    There are no real equivalents to those things in software development land. Everything is based on ideas, not physical laws. And the expression of those ideas can cut across an entire architecture. So you need someone who fully understands the tools being used - and the new tools being created out of thin air to capture ideas in different ways (e.g. XDoclet). Tech leads can do this - architects do not.

    To bring it back to your point - I've seen "real" projects like you've described. I've seen the damage "architects" wreak on such projects. Indeed - a very close friend of mine, who works for Deloitte & Touche, had to brought in _as a tech lead_ to repair the massive damage created by architects gone amuck.

        -Mike
  79. Once more (and again)[ Go to top ]

    Eventually, someone has to pick an implementation. That, I believe, is the role of the "Architect". Note that this just a role. The same person may indeed be the lead developer/guru/all-around-good-person.
    But when he or she decides which implementation(s) are going to be used to provide all of the requested features (which web framework, database, app server? use EJB's or don't? supporting tools?), he or she, at least temporarily, assumes the role of architect. These decisions--taken together--become the "Architecture," and they should be able to guide the detailed decisions that need to be made during development.
    If during development a feature or technical detail arises that challenges the chosen architecture, then the architect hat needs to come out again.

    Problem: How is the architecture communicated to the development team? How, without a bunch of code reviews, does one ensure that everyone is on the same page on a large system implemenation?

    Solution: MDA. The transformation templates--and the Platform Specific Model itself--is written or modified to match the chosen architecture.

    -Joe
  80. Once more (and again)[ Go to top ]

    I have no problem with someone wearing an architecture hat - I might have done so myself once or thrice. I do have a problem with an architect defined as a distinct individual whose primary purpose is to do architecture type things.

    \Joe Parks\
    Problem: How is the architecture communicated to the development team? How, without a bunch of code reviews, does one ensure that everyone is on the same page on a large system implemenation?

    Solution: MDA. The transformation templates--and the Platform Specific Model itself--is written or modified to match the chosen architecture.
    \Joe Parks\

    Again, this is a bottleneck. Practically speaking, you're going to run into these sorts of scenarios:

      - Plain old bugs in the transformations. Developers are DITW (dead in the water) until they're fixed.

      - Neuron misfire while creating the transformations - due to architect mistakes, the transformations don't actually match the architecture. Developers are DITW.

      - Transformations don't work for what a given developer is trying to do. D-DITW.

      - Transformation code is too slow for a subset of the code. D-DITW.

      - A component needs to be created outside of the current architecture for a tangent task (e.g. a feed from somewhere, daemon clean up task, what have you). D-DITW.

    When doing large-scale development, the thing you want to avoid more than anything else is bottlenecks. For example, things like large RDBMS systems are a pain in the ass in large systems development, because you end up with two choices:

      - Everyone uses one big RDBMS - bottleneck, collisions.
      - Everyone uses their own little RDBMS somewhere. No bottleneck, but there are often out-of-sync DBs and schemas.

    The same thing happens with mainframe feeds, ERP systems, etc. Developers learn that things quickly become bottlenecks, and find ways to break the logjam (while accepting that they're increasing other risks, like out-of-syncness).

    What you're describing is a big giant bottleneck _by design_. As you scale up to larger projects, it will become _more_ of a hindrance, not less.

        -Mike
  81. Good architects[ Go to top ]

    Mike, I believe that you have worked in a lot of projects and you have experienced what I have experiences in almost every project: The architect is no architect! He produces a lot of paper, desigs nice pictures and after all the developers build a system that works and has nothing to do with the paper.

    But you are talking about tools, technologies, etc. That is all technical lead stuff, yes. An architect has lots more to do. He has to understand the business, talks with the stakeholders (therefore needs a lot of experience) and after all has to SELL the architecture, so that the developers (including the technical lead) can implement this architecture and care about the technical details. I am not a fan of Powerpoint architecture diagrams...but no CIO wants to see Javadoc, UML diagrams or nice whiteboard designs.

    But this discussion is more about the definition of the role of the architect and we will not come to an end. You have many good points and I can share a lot of bad experiences with you, but I think the architect's role in a big project is essential.

    Mirko
    :wq
  82. Role of the architect[ Go to top ]

    I'm going to side with Rickard on this. A few months ago, I went to an OMG open day in Amsterdam to hear the latest on MDA, PIMs, PSM. I found then entire thing a buzz word convention. Of course the target audience to me was not developers but the slime of this world, project managers. People ohhed and awed at the the thought of having a platform independent model.

    The reality of course was that most people cannot model their way out of a plastic bag, not to mention manage a user requirements correctly. While MDA maybe a good intention, I cannot see it fitting into any of the business domains I've worked in. I can only see it in the hands of people that just give software engineering a bad name.

    The merit of the feasbility of MDA or the role of an architect are very much a different story...
  83. Role of the architect[ Go to top ]

    <quote> I think many people including Rickard misunderstand the role of an architect. An architect who gets his hands into code is not really an architect in my point of view.
    Lays an architect bricks? No. He designs the development plan and controls the work. I think he has to have good programming skills, so that he understands what is going on in the project and where the problems are, but he is more a leading personality than a "worker". This is the reason why many experts say that an architect must have at least 8 years of real development experience to become an architect.
    </quote>

    It really depends on the complexity of the project. Some projects have subprojects with subsubprojects with subsubsubprojects - each with 5 architects and 20 coders. It's litteraly impossible to have 1 overall "architect".
    It becomes organic. Some orgranizations only have product managers track progress.
  84. FYI: MDA[ Go to top ]

    For all who are interested in MDA discussion (we had this already in TSS):

    http://www.theserverside.com/home/thread.jsp?thread_id=20314

    Lofi.
    http://www.openuss.org
  85. AndroMDA and XDoclet not so different[ Go to top ]

    Well done to Rickard for dethroning the god-architect-priest-scribe that knows the holy UML. Too often have we seen middle management with medium intelligence being offered the emperor's clothes by people that have perfected the art of sounding intelligent. Too often has UML been used to sound intelligent.

    Just don't throw away the good with the bad. Have a look at AndroMDA. It has taken from MDA what is useful. In stead of writing repetitive code, us normal developers (not some UML scribe) just modify the Velocity template that is used to generate the code. Not too unlike XDoclet. Some people just prefer pictures, it seems.

    Ampie

    Just another programmer.
  86. UML is the problem...[ Go to top ]

    IMHO the real flaw of MDA is not its idea. It is its language. MDA is
    basically tied to UML by the OMG. Much has been set about UML of course. In my opinion, it is good at modelling static relationships to some extent. It is - like all graphic tools - a total desaster for modelling more complex (in fact quite simple) dynamic relationships.

    It just is not manageable. A very nice way to check this is to dive into a couple of "EAI" projects that use graphical modelling as well. This almost always leads to hard to read systems made up of literally thousands of diagrams for even the most simple purpose (like add a and b). This blind following of graphical modelling is a problem. Even more so, because in fact these diagrams are only understandable for computer programmers - I have never seen a business person who could understand an UML diagram - albeit the most simple ones. Some tools show a better "MDA-like" way. They employ languages that are in turn transformed to the different platform dependent models (for example using velocity models). The upside of this is that actual logic can be done on this layer rather easily. Because such approaches are most of time termed "code generation" and because they do not provide "nice pictures" they are nevertheless the real core of MDA and the one most likely to have an impact on real world software development in the long run.
  87. UML for describing behaviour[ Go to top ]

    I totally agree with your opinion on UML's limitations for descibing business logic. Using only UML for describing a real life project's dynamic behavior is just impossible. It's nice to have some state charts to illustrate some concepts, but is is impossible to describe even the simplest business rules like constraints and validation rules.

    UML is suitable as a communication media between developers, to bring some light on selected design details and to describe the static part of the problem domain. IMHO this is one of the reasons why those CASE approaches have failed.

    A good indication for it's inappropriateness is the number of different diagram types that exist to describe dynamic behaviour (each of them with it's own limitations, but none of them useful in a generic way), whereas in most projects class diagrams are sufficient to describe the static part of the application.

    In my opinion it is possible and reasonable to generate the static part of an application using MDA or whatever generator approach. This can be a real productivity boost, especially when it comes to changes.

    Furthermore I don't understand why the MDA people only limit the meta info's usage to generating code and not to describe the problem domain at runtime, too. This is indeed a very useful thing. The Jeeglue project (http://www.jeeglue.org) follows this approach, but it is not capable to generate from UML diagrams and therefore uses it's own meta language format: plain old Java.
  88. MDA not OMG or UML[ Go to top ]

    MDA doesn't need to be tied to UML. Nor is OMG the true
    source of what is MDA. It helps to Kkeep the idea separate from
    the implementations. If you are saying the OMG's idea of MDA
    sucks then i would have fewer issues with that.
  89. MDA not OMG or UML[ Go to top ]

    MDA doesn't need to be tied to UML. Nor is OMG the true source of what is MDA.

    So true. Shlaer-Mellor is a perfect example of how MDA can be better done with easier model diagrams than UML. But OMG did coin the phrase "model driven architecture". Prior to MDA it was called model integrated computing, generative programming, or model translation. But it is all the same thing. Only now it has a standard -- the one thing it needed most.
  90. Ask yourself this[ Go to top ]

    Why don't you program in assembly code any longer? Why do you program in Java / C++ / VB / C# / etc? Why? Because you know that you can express the requirements of the user domain - the stakeholder if you like - in your language of choice.

    What makes you think that models + textual semantics appropriatly combined will not, in the future, be able to do the same? Sure the written word is more powerful than pictures alone - thats why most "comprehensive" MDA tools use a fair amount of words as well! Do you all have that little faith in your future selves?

    MDA has always been to me:

    code = model + transformations + code

    the code is always fed into the next iteration - have people had success with MDA? Sure they have, MDA isn't a "standard" - it is an emerging discussion point with a long, long way to go. Personally, anything that can let me develop less code and use a higher degree of abstraction, thus allowing me to achieve a better result, faster is OK with me.

    I have seen uber-MDA in ArcStyler (http://www.io-software.com) and Model Driven RAD in BoldSoft's products (now Borland's ECO). Quite a spectrum, but all focused on delivering better, more maintainable applications faster.

    I don't care about Rickard's petty politics - MDA, with all its buzz words is here to stay.
  91. Ask yourself this[ Go to top ]

    I have seen uber-MDA in ArcStyler (http://www.io-software.com) and Model Driven

    > RAD in BoldSoft's products (now Borland's ECO). Quite a spectrum, but all
    > focused on delivering better, more maintainable applications faster.
    >
    > I don't care about Rickard's petty politics - MDA, with all its buzz words is
    > here to stay.

    What do you think about the non-technical issues I raised in the blog entry? Are they only "petty politics" to you?
  92. Ask yourself this[ Go to top ]

    Richard,
    I'm not sure about the assembly -> Java / C++ etc. comparison. This analogy is used widely when talking about MDA. However, languages like Java et al have the power to express everything that you can express in assembly plus much more. The current MDA approach of using (mainly) UML for modelling means that your model can only express LESS things than the language it will be turned into. Thus you have to add a whole lot more information about the target technologies, as well as actual code, before any model can be turned into a working system.

    Now, I'm not saying that turning models straight into working applications won't come in the future, but it seems much further off to me than the 5 years people are talking about for MDA. In my experience, two teams generally can't even agree on what persistence strategy/web framework/xml parser etc. to use. Until architecture if fully comoditised and you just pick the best architecture from a set of standards, MDA will remain effectively an application template generator. However, I have to say if you write a number of very similar applications to a common (comoditised for an organisation or particular purpose?) architecture then MDA can offer some real wins even in its current limited form.
  93. A Benefit of MDA[ Go to top ]

    I don't outright disagree with these comments, as even the conflicting ones can be true in different situations. Thought I'd add one more thing since I didn't see it mentioned:

    I perceived much of the value of MDA to be something to reduce the cost of maintaining and re-releasing a body of complex code inside an enterprise over time, where new engineers come on to deal with refactorings and subsequent internal releases in a corporate IT environment. This is something a little different than claiming MDA was a better representation for application architecture, or a tool for changing the architect-engineer team hierarchy, or what have you.

    I don't know how many folks here have inherited a large, sophisticated legacy application, or how many have to deal with enterprise and domain-specific apps in their umpteenth releases versus how many folks here get to build new applications and move around to new projects all the time, but MDA seems somewhat valuable in the former scenario. Certainly not as sexy as some of the stuff others have mentioned here, but it's a big expensive deal, particuarly keeping in mind that the corporate IT folks who inherit these apps and have to do upgrades are not as savvy as some of you are and may not be cream of the crop engineers.

    I do not know if models make understanding and augmenting existing applications less expensive or not, maybe models are even more complicated, or maybe that depends on the tooling and MDA implementations. But it seems possible that MDA could be somewhat helpful in that situation to engineers, all of whom are really architects regardles of what their titles say.
  94. A Benefit of MDA[ Go to top ]

    I don't know how many folks here have inherited a large, sophisticated legacy application, or how many have to deal with enterprise and domain-specific apps in their umpteenth releases versus how many folks here get to build new applications and move around to new projects all the time, but MDA seems somewhat valuable in the former scenario.


    Are you thinking of changing non-MDA legacy apps or legacy apps that (will) have been coded in MDA? I'm sceptical that MDA will be of any use for the former, except in that it might be possible to wrap the legacy app's interface in an MDA interface, and then code against the new MDA interface. As for the latter, well it is possible to create bad code in any language, and MDA isn't a protection against that!

    MDA isn't a silver bullet w.r.t. re-engineering or integration, whatever the salesmen might say.
  95. A Benefit of MDA[ Go to top ]

    Yes, I was thinking of apps in the future that will have been produced using MDA. I don't know if it's possible to wrap or reverse transform legacy apps into MDA models or not, but wasn't really thinking along those lines.

    I didn't use the word silver bullet, my phrase was "somewhat valuable." It is possible to write bad code in any language, as you say, and my experience in taking on apps in corporate IT is that we should always assume that the code will be bad. So I am wondering if it might be easier for certain kinds of corporate developers, who aren't masters of any language, to get up to speed and then iterate and refactor existing complex apps using visual models that abstract away some of the bad code or ugliness. Might the ugliness of the models and all the new problems they introduce nevertheless be easier to deal with in certain cases, for certain people, than the ugliness of the code? At least in certain circumstances for certain people?

    Of course it's no silver bullet -- but that does not mean it is a rubber chicken, good for nothing in any case at all, ever. Neither extreme view is necessarily true.
  96. A Benefit of MDA[ Go to top ]

    <snip>
    I don't know how many folks here have inherited a large, sophisticated legacy application, or how many have to deal with enterprise and domain-specific apps in their umpteenth releases versus how many folks here get to build new applications and move around to new projects all the time, but MDA seems somewhat valuable in the former scenario.
    </snip>
    No, MDA is valuable exactly in the latter scenario. In the former scenario it is most of the time a desaster (at least in the way "MDA" is understood now). Two words: Vendor Lock-in. You are locking in your large and sophisticated enterprise application on some MDA vendor and product that is likely not to be around for very long. Iek! Sophisticated, large enterprise application can easily be funded in a way that caters for professional documentation and maintenance friendly software design. If they are not, there are other problem lurking for sure.....

    On the opposite it is extremely useful in green-field fire-and -orget projects because it offers superior project completion times and less errors.
  97. A Benefit of MDA - reality check[ Go to top ]

    On the opposite it is extremely useful in green-field fire-and -orget projects >because it offers superior project completion times and less errors.

    I have actually seen a huge project in our corp driven by (PI)models/plug-in 'architectures'/skeleton-code/grunt-work . Something as close to MDA as you can image, but without the proper names (in those ancient times 3 years ago). It collapsed spectacularly, for two major reasons (IMHO):
    - the individual responsibility/ accountability is lost on such a project
    - the PIM ideology makes it difficult to leverage existing (platform-specific) stuff

    And on a really big project transparency and hijacking existing solutions are rather important.
    Not that the stuff is useless. Documenting the pre-coding ideas IS something we desperately expect one from another (to little avail :-( ), but that's just it.
    If you start believing in the 'magical' part of MDA for one second, you seem to be doomed.
  98. I think this discussion misses the point to a large degree. Are we really discussing if it is possible to generate an exectutable representation of a system from a human readable representation of the system? Haven't we done this for decades?

    I think we have three separate questions here:

    (a) Are picture languages more expressive and easy to understand than textual languages? Some poeple seem to imply that picture languages are more abstract than textual languages. I doubt that. I don't see why the words "class Person" are less abstract than a rectangle with the caption "Person". There is no difference in the abstraction level it's just a different syntax. UML uses exactly the same object oriented concepts just as any textual object oriented language. If there is a difference, then it is not a difference of abstraction levels. Why do we call a bunch of UML diagrams a "model" whereas we call Java source "code"? Why do we say "hand code" when we mean to describe a system in a textual language, whereas we say "to model" or "to design" when a picture language is used? The only justification would be to accept the premise that the picture language is in and of itself more abstract than the textual language. As I said, I see no reason why this should be the case.

    (b) Are there more useful general methodologies of abstraction than those provided by object orientation? I certainly do think so. Everyone who has taken the time to study the features of knowledge representation languages (like OWL or rules languages) will know what I'm talking about.

    (c) Do the platforms and language abstractions we use to build business systems today require too much low level technical, platform (J2EE, .Net, ...) specific knowledge? Even if it may be surprising, my answer is no. I think the way in which different systems use and combine the different mechanisms of J2EE for example, can make a huge difference in terms of scalability and extendibility. I doubt that I can take any general purpose generator (if it's called MDA or something else) and emit good enough code for an arbitrary mission critical system without just switching one specification language for another that is no more or less abstract than the first.

    BUT, what I do think is that in contrast to a tool vendor, an enterprise architect can in fact define a much simpler more abstract language that can and should be automatically translated into specific J2EE or .Net or whatever artifacts. Why is it possible that an enterprise architect can do what a tool vendor cannot do? Because the enterprise architect need not create a _general purpose_ language but rather a special purpose language or DSL (domain specific language). Again it doesn't matter much if this is a picture language or a textual language, the point is that more specificity and less generality means less explication of detail irrelevant to the particular problem domain.

    But it will be the architects and designers of the enterprise or consultants who create the mapping from domain specific abstractions to general purpose platforms because the enterprise is where this knowledge lives. And it will be enterprise developers who will code the mapping. There will not be less work, we will just create hugely more features in shorter time. Productivity growth that is. To the tool vendors, I can only say this: Give us means to create and maintain special purpose languages quickly and don't ask us to believe that you can create better general purpose abstractions than Sun, IBM or Microsoft. If anyone can do that, then it's the logicians or the AI research folk.

    Alexander
  99. \Alexander Jerusalem\
    (a) Are picture languages more expressive and easy to understand than textual languages?
    \Alexander Jerusalem\

    Ah, this is trivial to answer. The answer is: side effects.

    What are the side effects of constructing a Person class?

    What are the side effects of calling Person.ageOneYear()?

    Visual paradigms have completely failed at capturing the side effects of operations. They can model certain static relationships, and some dynamic relationships as well. But they suck at modelling propogation of state and state changes (summed as "side effects"). Visual modelling to date captures class structures and class items such as member variables adequately. What they don't capture is code like this:

       public Person ()
       {
          PeopleTracker tracker = (PeopleTracker)Services.retrieveService ("PeopleTracker");
          tracker.trackThisGuy (this);
       }

    Please don't argue the specifics of the above example - the point is that alot happens in the guts of method calls that are not reflected in the class or object relationships.

    \Alexander Jerusalem\
    (b) Are there more useful general methodologies of abstraction than those provided by object orientation? I certainly do think so. Everyone who has taken the time to study the features of knowledge representation languages (like OWL or rules languages) will know what I'm talking about.
    \Alexander Jerusalem\

    Certainly there are. One, which is strangely ignored by J2EE developers, are creation of domain-specific "little languages". Another may be AOP.

    I personally don't think MDA is a useful general methodology - it's tied too tightly to the tools.

    \Alexqander Jerusalem\
    c) Do the platforms and language abstractions we use to build business systems today require too much low level technical, platform (J2EE, .Net, ...) specific knowledge? Even if it may be surprising, my answer is no. I think the way in which different systems use and combine the different mechanisms of J2EE for example, can make a huge difference in terms of scalability and extendibility. I doubt that I can take any general purpose generator (if it's called MDA or something else) and emit good enough code for an arbitrary mission critical system without just switching one specification language for another that is no more or less abstract than the first.
    \Alexander Jerusalem\

    I agree with the above, but I'll go a bit further - what's wrong with creating an app-specific framework on top of J2EE? Just about every organization I know does this already, and it provides the majority of the benefits that MDA people are touting (but without the mess and the bottlenecks and buzzwords).

    Most CASEy-type frameworks (and despite objections, I'm lumping MDA in with CASE) seem to assume that developers are dumb, unable to create frameworks and abstractions, and always use _just_ language level classes (or, in the J2EE world, J2EE components). The justification in the CASEy tools is that the tool takes the drudgery out of the language, or the container, or the J2EE environment.

    But developers aren't that stupid. Most everyone has a standard base stateless session bean, they abstract out JDBC into a framework, they access JMS through app-specific factories - they create abstractions that provide standard behavior and constrain the wide-open J2EE standards to map what the app needs to do.

    The above approach is proven to work. The problem, I believe, is that there's no sexiness or handy buzzword for developers who do their jobs. Developers who isolate and modularize their code, and create standard mechanisms for using J2EE constructs, are achieving what MDA promises. They do it routinely, as part of their job description. But a vendor can't charge $10K a seat (or whatever) for common sense and intelligence.

        -Mike
  100. But developers aren't that stupid. Most everyone has a standard base stateless session bean, they abstract out JDBC into a framework, they access JMS through app-specific factories - they create abstractions that provide standard behavior and constrain the wide-open J2EE standards to map what the app needs to do.

    >
    And what about standardizing this "framework"? If everyone is doing this, or should be doing this, isn't it time for a standard to come up? And if MDA is this standard? Developers wouldn't need to create their own framework of common solutions anymore. MDA would crate it for them. Abstraction elevator, take me one level up, please.

    Don't get me wrong, I love to code. But I've also seen the same specification coded again and again (even in different systems for one company!!).

    I imagine what assembly programmers said the first time they saw a high level language and a compiler... :)

    (PS: I imagine also how many problems these early high level languages had back then... let's just wait and see what MDA will bring us in the future)

    Regards,
    Henrique Steckelberg
  101. \Henrique Steckelberg\
    And what about standardizing this "framework"? If everyone is doing this, or should be doing this, isn't it time for a standard to come up? And if MDA is this standard? Developers wouldn't need to create their own framework of common solutions anymore. MDA would crate it for them. Abstraction elevator, take me one level up, please.
    \Henrique Steckelberg\

    No, you miss the point - the "frameworks" I'm talking about are highly application specific abstractions of things like J2EE components. They encapsulate the local application architecture in many respects.

    As such - it can't be "standard", because every shop and every application is different.

    What you're advocating is kind of embedded in your post, but not explicitly pushed as such, is "common solutions". What generation after generation of developers and managers learn is that there are common solutions only to technical aspects of an application - threading, persistence, etc. in the most general sense. There are no common solutions to application problems. If you try to create, for example, a "Auction Framework for J2EE" which is supposed to work for many shops doing auction stuff, you will find that your efforts will fail miserably.

    In a given shop I may create my own Auction Framework, which is used, worked around, tweaked, refactored, abused, and ignored as appropriate by the development staff. It may be highly useful in my shop. But I can guarantee you 100% that it will be utterly worthless to another shop who's doing 90% of the same sort of thing. This is a fundamental truth of software development that managers and Type-A architects never get, and that good developers know instinctively (but often only sub-consciously).

    What you are looking for can, of course, also be put into other, simpler terms: you are looking for someone to do your work for you. This is a noble goal (laziness is the root of all great code), but I'm afraid in this sort of case it's not going to work.

        -Mike
  102. Mike,
          GREAT! I couldn´t agree with you more.
  103. I imagine what assembly programmers said the first time they saw a high level language and a compiler... :)

    > (PS: I imagine also how many problems these early high level languages had back then... let's just wait and see what MDA will bring us in the future)
    >

    Henrique, I think you are the victim of a very common misconception with this assembly/high lever language (3GL) comparison. Assembly and 3GLs work on fundamentally different conceptual levels. In assembly there is no loop, no function, no if, generally no structural programming concepts. 3GLs are higher level than assembly because they do have all these higher level concepts.

    MDA uses UML as a language and UML is an object oriented graphical programming language. It has the same concepts and abstractions as any other object oriented programming language: classes, methods, fields and so on. There is no difference in the abstraction level between UML and any other OO language.

    There are many ways to abstract away J2EE specifics that you don't need for a particular project. They range from general to enterprise or domain specific frameworks, ANT scripts, X-Doclets, various XML based generation and interpretation techniques, DSL, etc. The only thing that separates MDA from some of these more common techniques is the use of a picture language to describe the system.

    I'll leave it to you to decide if you prefer to manipulate the very same conceptual abstractions with the mouse, trying to move small styled line endings on millimeter wide boxes that come up only when you move the mouse over them or if you prefer to write a line of code or if you prefer to use the text and form oriented refactoring tools of, say, Eclipse. It's a matter of taste I guess.

    If we want to move on to higher levels of abstraction, we should talk about these abstractions. We should talk about the limitations of the object oriented class concept for example. And on a meta layer, about the whole process of forming new abstactions in the first place. But let's not be detracted by syntax questions like if it's better to paint a box or to write a word when both have exactly the same semantic meaning and level of abstraction.

    I really wonder why so few people talk about the things that are really badly supported today. For example, if a class is supposed to be a business concept, why can't a business expert introduce a new class or a new field or a new relationship of a class at runtime? And why can classes only be defined based on static properties but not on the basis of dynamic state? What I want is for a business expert to be able to say: Dear up and running system, here's my new class of customers that have bought more than 20 books in the last year and this class shalt from now on be known as GoodCustomers.

    These things are so common of course, that we all found solutions for it a long time ago. We relegate the whole crappy object oriented type system to the purely technical level and re-create our own much more dynamic type system in the database. Everyone who has never created database tables with names like CustomerType and bound business rules to them please stand up. Everyone who has never provided for the addition of new fields at runtime by using some kind of name-value pair mechanism, please stand up as well.

    There are so many annoying deficiencies in today's software architectures, platforms, tools and languages that have to do with lacking support for runtime dynamics that I'm really sceptical about solutions based on code generation no matter if they use pictures or text for expressing the same old limiting abstractions.

    Alexander
  104. Alexander,

    I agree with your opinions.

    <quote>
    MDA uses UML as a language and UML is an object oriented graphical programming language. It has the same concepts and abstractions as any other object oriented programming language: classes, methods, fields and so on. There is no difference in the abstraction level between UML and any other OO language.
    </quote>
    Yes, this is true. Therefore you have such a tool like Together, which can switch the view from "model" to "code" and vice versa. Using stereotype and transformation in UML is just the same way using XDoclet (meta data) in Java. The difference is just the view.

    I hope that the meta data introduction in JDK 1.5 would give us a better way to extend the language itself (like what XDoclet has done) because we need an easy way to extend Java.

    Regards,
    Lofi.
  105. I imagine what assembly programmers said the first time they saw a high level language and a compiler... :)

    > > (PS: I imagine also how many problems these early high level languages had back then... let's just wait and see what MDA will bring us in the future)
    > >
    >
    > Henrique, I think you are the victim of a very common misconception with this assembly/high lever language (3GL) comparison. Assembly and 3GLs work on fundamentally different conceptual levels. In assembly there is no loop, no function, no if, generally no structural programming concepts. 3GLs are higher level than assembly because they do have all these higher level concepts.
    >

    I'm sorry, but there are IFs, Loops, and function calls in assembly. You can do structured programming in assembly, even, using macros. These are basic concepts that existed since day one of programming (well, almost). The difference between the generations is the abstraction: the level of detail. But the concepts behind have always been the same.

    And Mike, I've seen too many projects die because of bad analysis. You can have 1000 genuses coders, but it takes 1 bad analyst to kill the project. But the same project could succeed if you have 1 genius analyst and 1000 code monkeys.

    Regards,
  106. \Henrique Steckelberg\
    But the same project could succeed if you have 1 genius analyst and 1000 code monkeys.
    \Henrique Steckelberg\

    A good analyst can make a difference - but not on the order you're implying. You really need good people on both sides of the fence.

    BUT - please keep in mind, there can _literally_ be no application without the developers. You can code without an analyst, without a project manager, without QA people, without just about any non-coder role. The results may not be great, but coders can code without certain up-front people involved.

    However, the flip side is not true. All the greatest analysts, project managers, QA people, and Architects won't mean a hill of beans if you have mediocre or poor coders.

        -Mike
  107. Hi!

    I couldn't resist to comment this. Sorry it's a bit long!

    I also commented this on my blog at

    http://www.freeroller.net/page/hugopinto

    Feel free to comment there and/or here.

    A prelude, first: as you, kind reader, may infer from my previous posts, I’m not a blind-MDA advocate. Actually, I’ve been referring to a certain kind of CASE tools that I believe definitely come in handy when building a specific kind of applications. With this in mind, please note that I do not believe that, at this time, MDA is a viable solution for building EVERY kind of application.

    Rickard> What disturbs me the most with MDA is not the "silver bullet" heraldry of it being the final solution to how we can now finally program using models, something which has been said before and never happened properly due to the complexities of round-robin modifications between models and code. No, what disturbs me the most is the view of reality that one must adopt in order to accept its, almost religious, promises.

    I’ll keep on with my assumption that we’ll be using MDA-like techniques in the near future to build what we usually call “Enterprise Applications” – check SAP, for example, for an idea of what I mean. I do believe, however, that building such an application can require a certain methodology – a set of rules to follow when defining stuff (first you define requirements, then group them in use cases, then, for each use case, define it’s behavior, etc etc etc). This should not be a religion, however. Such a tool-based environment would allow one to manipulate multiple views of this models, tweaking the model in any of it’s parts (note that I’m not saying “hacking code”, since someone that models an “Enterprise Application” should never see a line of code), as indeed is needed in any iterative development cycle.

    Rickard> MDA centers around the idea that it is possible to create models of an application that are platform and implementation neutral, and which can then through a series of transformations (largely automated) be converted into code, thus allowing the developer to ignore the details involved with architectures that are used to implement the models. Right there I think most developers' BS meters are triggered.

    You said it right – most “developers”. The idea behind building such applications is that someone non-technical can define a model that represents a business solution. This is clearly not a developer. This is also the main reason why I believe that this kind of techniques is only applicable to the application subset that deals exclusively with business problems, and not with technological ones. I may define that an account transfer is actually the decrement of the amount on account one, plus the increment of the amount on class two, and I’m still not specifying any technology choices. On top of this specification, I can then ASSUME (that is, choose) a series of architectural and technical options (is it Java?, is it .NET? Is it Entity Beans? DAO? AOP-ified POJO’s?). However, building such a model is only possible when you don’t capture technology detail – that is, when you model pure-business information.

    Rickard> The assumptions are that a) it is possible to create models that capture the requirements of the application

    From my belief, only for non-technology solutions.

    Rickard> and b) these models are better than writing code.

    Well, this is where it becomes complicated. What do you model your business domain with? Plain UML? From my experience, this becomes boring and non-productive – plain UML has little expression for high-level application description such as the ones I’ve been detailing. Stereotyped UML? Well, yes, this can add some expressiveness, but nonetheless you’re abstracting your model from assumptions you make on the stereotypes, and these assumptions should be clearly specified too. Other language? A visual language? A scripting language? This is a very sensible point to me ,as I’m really afraid UML may not be quite the right choice for visually specifying systems. But hey, it works, and I really won’t focus on a new language right now.

    Rickard> Personally, my experience is that neither are correct, at least not for any so-called serious application (Note to self: I wonder how many MDA tools are implemented using MDA).

    Adding to your note: yes, of course. Any MDA (as an Enterprise Information System that it is) tool should be able to build a tool with similar functionalities within its own framework. From my experience with code generation, however, you’d end up building a tool with functional front-end that matches every functionality you specified, but has strong productivity (not usability) issues, since it would be like defining a business solution using a SAP-like interface. This is doable, but terribly boring. Such applications (MDA tools) demand a degree of interactivity that I believe pattern-based, model-based development, is not up to the job these days without an extra effort that would supplant the original effort of building the application with plain code. You’re taking about a generic MDA tool that could build any application – including, why not?, itself. I don’t think any vendor on the market will give you this.

    Rickard> Most MDA papers and articles that I have read to date state that these transformations are to be done by highly skilled individuals (aka "architects"), which will then allow lesser mortals (aka "developers") to create applications by doing models which are then transformed into code.

    Yes, and I hate this description. Your so-called lesser mortals should never be caller developers, nor be hierarchically inferior to the god-like architects. In the business-specific solution, they know about how the business works, they’re the stakeholder’s hands and eyes in the IT industry’s realm.

    Rickard> It is explicitly noted that creating such transformations is difficult. It is then said that individuals with specialized coding skills are going to become obsolete since one can now let cheap off-shore developers use MDA to create applications. Comparisons with the computer- and car-industry are common in MDA articles and literature.

    Comparisons with the computer- and car-industry SHOULD be made when you’re not dealing with computer applications anymore. I don’t think that what our industry lives on top of is anything more than THE SAME APPLICATION, written over and over again, just changing names, and adding add-list-modify-remove to everything. This is a process that CAN and SHOULD be optimized, since the only thing that effectively changes is the business domain underneath.

    I do agree with you that this rule-of-thumb CANNOT be applied to the rest of the industry – there are plenty of non-add-list-modify-remove applications that need to be built. But isn’t it plain stupid that we STILL build those from scratch? (well, almost from scratch, in many parts thanks to you – XDoclet anyone?)

    Rickard> This is the scary part. Individuals are effectively pigeonholed based on their title ("architect" or "developer"), and there seems to be little incentive for individuals in the "developer" slot to learn more and work towards acquiring "architect" status. Why? Since all they are doing, with the wonders of MDA, is to create models which they use to build the applications. In other words, there does not seem to be any natural knowledge transfer, and teams will become even more hierarchically tied to the title one has acquired.

    Rickard, Here we diverge. For general-purposed software development, this is not an issue, as I don’t think, as said before, that a tool will come in the next few years that will solve all our problems. However, for the Enterprise Application “niche”, this has become a problem: we’re not even building software anymore – we’re reconfiguring the same application over and over, writing it form near-zero. The development problems are pretty much solved. The solutions are already found and quite established. This begs to be fine-tuned and optimized. And it also begs for me to find a better thing to do in my life as a developer than to write over and over the same f****ng application. “With the wonders of MDA”-like techniques, I’ll be able to do just that: to go program games, or whatever I love. I don’t think that in a pure business-modeling environment, there should be any “architects” at all. My company would buy the “Full J2EE web-based configuration stack” from ACME Modeling Co., and use it to build their business solution on. I’d be happily programming, or designing, elsewhere, as my company’s focus wasn’t originally on developing software, but business solutions. Software was just the mean to an end – and I was the necessary evil. I don’t want to be the necessary evil anywhere.

    Rickard> To me this is a fucked up view of reality. It is encouraging a mentality that I believe is elitistic and contrary to the spirit of both OpenSource and XP programming.

    Coolest. Why on earth should a programmer spend his/her 5-years university training by building “client has many addresses”-kind of applications. I think that these guys shouldn’t even be PROGRAMMING these applications in the first place.

    Rickard> It also encourages developers to not understand what they are doing, since such details are dealt with by the transformations created by the architects.

    Yes, but they wouldn’t be developers in the business-specific solution.

    Rickard> This obviously lowers the demands on the knowledge that developers using MDA needs, and as such I have no doubt that it will become immensely popular in certain circles, and will no doubt help rationalize many developer organizations.

    I definitely hope so. I’m dead-tired of doing the same over and over and over again. Should I be so lucky that I had the time to dedicate myself in full time to such project, take my word that I’d do it myself.

    Rickard> However, I'm also pretty certain that I myself, and anyone I work with, will never ever use MDA. I hope this one will rest in peace in the not too distant future.

    Au contraire. I just hope it flourishes. So bad, so bad, that software engineers won’t have to write non-“software engineering” solutions anymore.

    Warmest Regards,

    Hugo Pinto
  108. MDA and XDoclets[ Go to top ]

    Hugo

    While I think you and I agree on most of the points raised on this thread, I have to disagree with you on a couple of them.

    Hugo> I’ll keep on with my assumption that we’ll be using MDA-like techniques in the near future to build what we usually call “Enterprise Applications” – check SAP, for example, for an idea of what I mean.

    I doubt that that we will see systems on the scale of SAP/Siebel being designed by a single team using MDA or MDA-like techniques. Why? Because it's unlikely that anyone will continue to build monolithic systems soon, instead focusing on "Composite Applications" (think EAI-oriented business process apps). It's also unlikely that MDA will be used to build these "Composite Applications", because the concept of a "Composite Application" is based on the idea that the underlying model is distributed and pieces of that model may change often and be beyond your control.

    Where MDA may fit is in building let's say a small-to-medium-sized app that offers business-specific functionality. Frequently these will be departmental apps that need to be built with the idea of integrating them into a larger infrastructure. They will contain a set number of use cases, a limited number of component types (that may be shared within an organization), and well-defined access interfaces (or services as the SOA group would say). For here, more SOA-oriented teams would create the user interfaces and build the composite apps the end-users see.

    However, even here I don't see MDA offering universal benefits. Some of these apps will be very tied to the DB, meaning that I can design my MDA model and generate the DB schemas or let my DBAs manage the schemas directly, which is probably more likely for skillset, political, and other reasons. Other apps will be almost entirely BPM-oriented to existing legacy code. MDA will be useful to some groups, but I cannot see it gaining the pervasiveness to make it an assumed part of any project.

    Hugo> ...there are plenty of non-add-list-modify-remove applications that need to be built. But isn’t it plain stupid that we STILL build those [add-list-modify-remove apps] from scratch? (well, almost from scratch, in many parts thanks to you – XDoclet anyone?)

    Since you know my alligences to BEA, you shouldn't be surprised that I think the concepts behind XDoclet (and WebLogic Workshop) solve the productivity issue better than generating code from an MDA tool. For me, if I don't what to write the code, why would I want to see it (think Servlets, for example). It just seems logical to create these new component types that are understood by the execution environment and don't require me to open a file will comments everywhere saying "DON'T TOUCH THIS", "MODIFY AT YOUR OWN RISK", etc.

    Of course, you are dependent on how the execution environment executes your component. That's the same as saying there are good-performing EJB containers and really bad-performing ones.

    So at least we can agree that is IS PLAIN STUPID to build those CRUD apps from scratch!
  109. MDA and XDoclets[ Go to top ]

    Where MDA may fit is in building let's say a small-to-medium-sized app that offers business-specific functionality.

    Ie, 70% of the mainstream software development scene, including 95% of the Java scene. A slam dunk.
  110. MDA and XDoclets[ Go to top ]

    Monte, it's always nice to discuss this stuff with you!

    Monte> I doubt that that we will see systems on the scale of SAP/Siebel being designed by a single team using MDA or MDA-like techniques. Why? Because it's unlikely that anyone will continue to build monolithic systems soon, instead focusing on "Composite Applications" (think EAI-oriented business process apps). It's also unlikely that MDA will be used to build these "Composite Applications", because the concept of a "Composite Application" is based on the idea that the underlying model is distributed and pieces of that model may change often and be beyond your control.

    Agreed. My SAP commentary was just me trying to showcase the typical behaviour of such application. Moreover, it comes as curious that you also think EAI-oriented business apps. I've been looking at communication protocols as "aspects" of enterprise systems - however, do note that I may be well off, hum?


    Monte> Where MDA may fit is in building let's say a small-to-medium-sized app that offers business-specific functionality. Frequently these will be departmental apps that need to be built with the idea of integrating them into a larger infrastructure. They will contain a set number of use cases, a limited number of component types (that may be shared within an organization), and well-defined access interfaces (or services as the SOA group would say). For here, more SOA-oriented teams would create the user interfaces and build the composite apps the end-users see.

    Agreed.


    Monte> However, even here I don't see MDA offering universal benefits. Some of these apps will be very tied to the DB, meaning that I can design my MDA model and generate the DB schemas or let my DBAs manage the schemas directly, which is probably more likely for skillset, political, and other reasons. Other apps will be almost entirely BPM-oriented to existing legacy code. MDA will be useful to some groups, but I cannot see it gaining the pervasiveness to make it an assumed part of any project.

    I do, for a very specific subset of problems - the ones I mention at my blog entry. I believe that the advantage of using such MDA-like (please note the "like") tools will be so convincing that it will just "buy" its way in with the reduced costs and gained productivity. Note, however, that this is, nowadays, a "niche" phenomena.


    Monte> Since you know my alligences to BEA, you shouldn't be surprised that I think the concepts behind XDoclet (and WebLogic Workshop) solve the productivity issue better than generating code from an MDA tool. For me, if I don't what to write the code, why would I want to see it (think Servlets, for example). It just seems logical to create these new component types that are understood by the execution environment and don't require me to open a file will comments everywhere saying "DON'T TOUCH THIS", "MODIFY AT YOUR OWN RISK", etc.

    Monte, I'm a strong tool advocate. Such a strong advocate that I don't even talk about "code" generation. Such code (or however you decide to specify the business logic) could even be interpreted in a runtime environment.

    Monte> Of course, you are dependent on how the execution environment executes your component. That's the same as saying there are good-performing EJB containers and really bad-performing ones.

    Long battle, just as the J2EE one was/is.

    > So at least we can agree that is IS PLAIN STUPID to build those CRUD apps from scratch!

    Agreed. Let's have a beer. ;)

    Hugo
  111. Rickard has likely never succeeded at model compilation, and this surely would cripple his appraisal. Some of us have had success and its concomitant epiphany.
  112. Is UML Turing-complete?[ Go to top ]

    I've always wondered, is UML Turing-complete? Or if you are saying MDA != UML, whatever the modeling language you use, is it Turing-complete? If it is not, doesn't that significantly restrict your problem domain, as opposed to using a general-purpose programming language like Java which is Turing-complete?
  113. Turing complete[ Go to top ]

    UML itself it's not turing complete. But they are going to make it turing complete (with help of OCL, etc.) in the long term I think. That's why I always see UML + MDA + OCL + ... as a "top down" approach and Java with meta data, Ace project + ... as "bottom up" approach. Just wait and see who will survive ;-)

    Lofi.
    http://www.openuss.org
  114. Now I've got the uber solution[ Go to top ]

    Hey, do we really need to HAND PAINT all these clunky diagrams? Can't we just generate them with a few lines of code? ;-)

    Alexander
  115. depressed :-([ Go to top ]

    This is the most depressing thread I have ever read....
    Software Engineering must be the most confused and pathetic discipline on the planet.
    Matt
  116. depressed :-([ Go to top ]

    Your first mistake was to assume "engineering" belonged in the title... Standish likes to remind our industry how wonderful we perform each year...
  117. depressed :-([ Go to top ]

    Software is a pathetic discipline because there is not one
    clear best way to do it. I can argue MDA. I can argue XP.
    I can argue OO, FP, logic, erlang, state charts, etc.
    Yet i can't prove to myself or anyone that anyone approach
    is best.

    The leaves a room for a lot of interference patterns.
    Approaches that work for small programs don't work for large
    ones. Approaches that work for one person's mind won't work
    with a person with a different mind set. Approaches that
    work for small colocated teams don't work with large distributed
    teams. Approaches that work for IT won't work for safety
    critical apps. Approachs that work for embedded systems
    won't work for approachs in a large workstation. Approaches
    that work for the mathematically fit won't work for the
    crafts people. And so on.

    How can the state of software be any other way?
  118. depressed :-([ Go to top ]

    Software is a pathetic discipline because there is not one clear best way to do it. I can argue MDA. I can argue XP. I can argue OO, FP, logic, erlang, state charts, etc. Yet i can't prove to myself or anyone that anyone approach is best.

    Bzzzt. Wrong. Market competition exerts selective pressure on development shops. Evolution is driven by this. Eventually some development paradigms will appear to us as natural winners. As an optimist I believe the winning ways will likely be the most fun.
  119. depressed :-([ Go to top ]

    Thank you for your buzzer impression. Very original.
    What does evolution have to do with what is best?
    Will evolution magically change the minds of software
    developers to accept the "natural winners"? I have
    not seen this in software even though we have had
    competition for 40+ years.
  120. depressed :-([ Go to top ]

    Interesting thesis, but it doesn't seem to match reality. In the 14 years or so I've been developing, I've seen 3 or 4 cycles of new generations re-discovering the lessons of the previous ones. There have been some advances, to be sure - but the fundamental principles of creating software haven't changed. Some new things have been picked up, particularly around OO, but I still have to worry about FIFO queues, performance, scalability, managing module and schedule dependencies, backwards compatability, etc.

    Sadly, each new generation seems to have re-learn the lessons of FIFO queues, performance, scalability, managing dependencies, backwards compatability, etc.
    Most often this is because they get focused on some new thing that will take the world by storm (MDA) and suddenly believe they can get away without knowing the basics.

        -Mike
  121. A friend of mine, Stan Sewall, is up for a Standish award for doing a project using MDA. Check out the OMG website: http://www.omg.org/mda/mda_files/NationalServicesIndustries.htm
  122. My view of my software development teams efforts is simply to Deliver Business Value. Here's how I've been honing my methods and tools over the past decade.
    Possible Keys to Success?
    I have humbly observed that my teams can successfully develop applications by following these three principles (and #2 is kind of a corollary to #1):
    Separation of Concerns
    Model your business first (problem domain). Keep it separate from UI, persistence, messaging, etc. Deliver business features that clients are willing to pay for. Do you think clients ask for Stateless Session Beans? JSPs? no... these are merely today's whizbang technology (and they will not be here 5-10 years from now).
    Duality of Architecture
    Design your application architecture to reflect the business needs. Major feature sets to reflect things like Order Management, Customer Management, Bill of Materials, Portfolio Mgt, etc.
    Next, design (or purchase) the technical architecture upon which the application features have to be built. (Unless, of course, you want each developer to figure out their own way to persist and display their assigned features.) Have the developers be creative on the application features, not redesigning the technical architecture all of the time.
    Agile Development
    As one of the authors of the Agile Manifesto, you can guess this is dear to my heart. (Hang out on Scott Ambler's agilemodeling forum on topica and you'll see some recent posts on these topics -- http://www.topica.com/lists/agilemodeling/read/message.html?mid=1714508008&sort=d&start=14328)
    Basically, I only trust measuring progress through running software -- as long as it is built on a solid architecture (vs a pile of spaghetti, or 5000 line JSPs stuffed with SQL, or VB with business logic in button presses). I like to drive my teams through short iterations, building one feature at a time. Estimating feature completion over a short time period, you know... Life is much simpler this way.
    ------------------
    I have practiced and improved these core principles for the past 10+ years. Likely, they will serve me for the next 10+ years.

    Oh, I forgot to mention MDA. Darn. I'll get to it next post.
  123. Eating your own dog food[ Go to top ]

    (Note to self: I wonder how many MDA tools are implemented using MDA).


    Sorry, I couldn't resist this one. MDE (and MDA tool) is generated using MDA from a model of the tool. Just one example of the feasibility of MDA. We could never have created the latest version of the product with the limited resources at our disposal using traditional dev methodology.

    Disclaimer: I am with Metanology, maker of MDE.
  124. A compiler is a MDA tool generating one kind of code from low level
    program model. Compilers (an MDA tool) are written in the very language
    they are written. This could happen in MDA too -- I do not see any
    compeling reason to preculde this.
  125. A compiler is a MDA tool generating one kind of code from low level
    program model. Compilers (an MDA tool) are written in the very language
    they are written.


    Please, we'll have no logic invading this discussion!

    ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  126. It's an interesting parallel.

    Now consider - how much work goes into building a compiler? How flexible is it's "model"? How much work does it take to retarget a compiler to generate good code for a new chip?

    How often does a compiler's internal DAG and symbol table representations change? How often do you retarget a compiler?

    How hard is it to fix a code generation bug in a compiler that generates "good code" (I know - it's damn, damn hard!).

    Now imagine 3 or 4 orders of magnitude greater number programmers trying to do the same sorts of things in their MDA models and transformations on a daily basis - the kind of work that gives compiler experts headaches and ulcers.

        -Mike
  127. Now consider - how much work goes into building a compiler? How flexible is it's "model"? How much work does it take to retarget a compiler to generate good code for a new chip? How often does a compiler's internal DAG and symbol table representations change? How often do you retarget a compiler? How hard is it to fix a code generation bug in a compiler that generates "good code" (I know - it's damn, damn hard!).

    If only you considered how many dozens of pluggable back ends the Gnu C Compiler has. What an excellent example of reusable general purpose automation. Presumably you don't advocate source compilation by hand, so why do you so stubbornly insist that hand interpretation is the only viable downstream use of formal diagrams? Surely you've heard of XMI and XSL working together to generate source code and other material from UML. This is very obvious stuff based on years old standards for XMI, UML, and XSL. Heck, the famous BridgePoint tool was doing this kind of work before the World Wide Web was born. It's decidely not rocket science. What a shame to be a software architect in ignorance of this basic technique for saving labor, reducing defects, and boosting job satisfaction.

    Rickard is right about one thing: spirituality is thin here at times. But only, I think, because developers are afraid to admit that the treadmill they've honed on for so many years might be a temporary artifact of software's early primitive era. Moore's Law is most definitely bent on changing the nature of our software development work. We'll always get more computing power than today's methodologies expected. Some developers might intuit from this a trend favoring charismatic business domain skills over savant hackability.

    Now imagine 3 or 4 orders of magnitude greater number programmers trying to do the same sorts of things in their MDA models and transformations on a daily basis - the kind of work that gives compiler experts headaches and ulcers.

    You've obviously never contributed to a model driven architecture. It is much easier than maintaining a traditional compiler. And much more fun.
  128. MDA and ontology are close concepts. It is tiring to see the war
    over syntactic details such as which XML schema is right. For
    example with widespread adoption of XML -- what have we achieved.
    Just the parser reuse and NO MORE. Things like "formal concept
    analysis", "representation theory and application" are more
    important than Model Driven Code Generation.

    The above rant could easily be termed off topic -- but this
    debate is getting tiring. Can't we get past the syntactic
    details such as code generation and get past representaional
    issues?
  129. For example with widespread adoption of XML -- what have we achieved. Just the parser reuse and NO MORE.

    Totally declarative. Oh, the parsebilities!


    Things like "formal concept analysis", "representation theory and application" are more important than Model Driven Code Generation.

    Indeed.


    Can't we get past the syntactic details such as code generation and get past representaional issues?

    Just as soon as you can show ontologies are Turing complete.
  130. Eating your own dog food[ Go to top ]

    OptimalJ team uses the Architect Edition (which allows custom transformation patterns to be written) to produce a lot of OJ's code. After all, anything that is tedious and repetitive and based on a domain model is a prime target for automation :=)
  131. MDA's Foundations: Flawed?[ Go to top ]

    MDA, as I see it, is based on two pseudo "axioms".

    First, the business requirements are the most important part of development. Whether the system is developed in .NET or Java, even if the system can support millions of users with nanosecond response times, if it doesn't do what the business users want/need, then it is crap. Conversely, if a system completely satisfies the business need, no one in the business truly cares how you did it, as long as you can maintain it. This is why, for example, I feel that Fowler's "Analysis Pattern" is far more useful than the GoF's "Design Patterns".

    Second, a large part of development is repetitive, both within and across projects. Even using something like XDoclet with IDE support, constantly filling out the template for "@ejb.bean name=...." grows boring--and error prone (the type attribute of @ejb.transaction is very much case-sensitive).

    MDA embraces the first, and obviates the second.

    -Joe
  132. Rickard,

    ever heard of the person sitting in the glasshouse throwing stones at people? Your comments and thoughts are lots less provable than what any MDA advocats have to say. I agree, some go a bit over the top. But the rest of your stuff is just as BS-prone as theirs. Example: You write "I wonder how many MDA tools are implemented using MDA". We use ArcStyler to write ArcStyler. We generate the entire repository infrastructure by simply downloading the latest versions of the metamodels from the OMG webserver. We generate about 90% of the profile implementations that map from some proprietary MOF-expressed metamodel to UML. We use ArcStyler to generate >90% of the implementation of the model transformation cartridges that we specify in UML models. The ways in which we and BTW all our customers use the product doesn't in any sort create this chasm that you're trying to envison between developers and architects. That chasm only comes along by people like you dwelling on this artificial separation.

    Are you still having fun programming you assembly stuff? I hope you're not using any 3GL, not talking about OO. That was the ivory tower stuff of the nerds who tried to rid the good old guys who knew how to do their assembler of their jobs... Seriously, start thinking.

    -- Axel
  133. Hello Rickard,

    thanks for your opinion. Which MDA tools have you tried? I've started with ArcStyler and it works well and is filling my expectations.

    As an IT-student, I've been spending a lot of time lately getting to know various technologies - and especially MDA. My humble opinion: it's a right way and already working reality.

    I cannot think of doing my (so far) little projects and homeworks (for example Java, .NET) without MDA and ArcStyler anymore. Using models (platform independent and platform specific), getting complete fan-out for testing and development, debugging system at the model level are making most fun..
  134. I think, Rickard, that you should ride along with a team that is actually using a Model-Driven Architecture tool and development process. I would imagine that some team would even pay you for the privilege. (I'm not being sarcastic; given your reputation, I'm sure you have no problem getting consulting/mentoring gigs.)

    That is, see for yourself whether the team actually shows productivity gains.

    And come back and post: were the ones doing the modelling seen as an "elite" group on a pedestal? Or was modelling just another activity in the development process?
  135. Particularly absurd is Rickard's suggestion that "one can now let cheap off-shore developers use MDA to create applications", implying that MDA might become a threat to Amerikan hackers. Obviously Rickard's crystal ball is hallucinating. By eliminating rote in software development, MDA makes developers more productive, which lessens the incentive for off-shoring. And by emphasizing business analysis, MDA also puts a premium on the proximity of customers and developers. This is sad in a way, since having worked remotely with German, French, Bulgarian, Indian, and Canadian teams, I know they're worthy of more core development work. MDA makes it less likely that foreign teams will be included in satisfying Amerikan demand for custom software.
  136. Particularly absurd is Rickard's suggestion that "one can now let cheap

    > off-shore developers use MDA to create applications", implying that MDA might
    > become a threat to Amerikan hackers. Obviously Rickard's crystal ball is
    > hallucinating.

    Yes, it's quite absurd. Here's the quote with context:
    "Most MDA papers and articles that I have read to date state that these transformations are to be done by highly skilled individuals (aka "architects"), which will then allow lesser mortals (aka "developers") to create applications by doing models which are then transformed into code. It is explicitly noted that creating such transformations is difficult. It is then said that individuals with specialized coding skills are going to become obsolete since one can now let cheap off-shore developers use MDA to create applications. Comparisons with the computer- and car-industry are common in MDA articles and literature."

    Obviously Brian could use a reading course, because somehow he managed to hallucinate away the part about these ideas being in pro-MDA articles. How ironic. Or maybe just sad?
  137. Misattribution is indeed the issue here. To MDA evangilists you misattributed the absurd belief that MDA would help cheap foreign labor to undercut domestic talent. No MDA evangilist has ever claimed this, and I gave some technical reasons. So sycophantic was your blog entry that several experts in this ServerSide thread raised doubts that you were truly privy to the MDA envagilist's perception. And when I noted that your blog's rant "was mostly FUD", you then asked me for examples. One such example that was central to your rant is this straw man of yours that MDA insiders predict labor globization as a consequence of the innovation.
  138. Misattribution is indeed the issue here. To MDA evangilists you misattributed

    > the absurd belief that MDA would help cheap foreign labor to undercut domestic
    > talent.

    I was merely restating what pro-MDA articles, with statements by both MDA people and analysts, were saying. If you find them absurd that's not much I can do about.

    /Rickard
  139. Brian: To MDA evangilists you misattributed the absurd belief that MDA would help cheap foreign labor to undercut domestic talent.

    Rickard: I was merely restating what pro-MDA articles, with statements by both MDA people and analysts, were saying.

    Such innuendo is an ingredient of FUD. You bashed MDA evangelists for supposedly holding distorted perception, yet your above claim can so far only be taken on faith. Undoubtedly real names won't be forthcoming.
  140. Brian: To MDA evangilists you misattributed the absurd belief that MDA would

    > help cheap foreign labor to undercut domestic talent.

    >
    > Rickard: I was merely restating what pro-MDA articles, with statements by
    > both MDA people and analysts, were saying.

    >
    > Such innuendo is an ingredient of FUD. You bashed MDA evangelists for
    > supposedly holding distorted perception, yet your above claim can so far only be
    > taken on faith. Undoubtedly real names won't be forthcoming.

    Here's one example:
    http://www.compuware.com/pressroom/news/2002/1316_ENG_HTML.htm

    I think CompuWare qualifies as "MDA evangelists", and the article is pretty clear on how they see it increasing the productivity of off-shore development teams.

    The main idea behind this conclusion is not so difficult to understand: if MDA can make knowledge from experienced programmers available to anyone as pre-coded transformations, then these become more easily reused by junior developers. That is, after all, much of the whole point of MDA.

    My concern is that this can create systems which are hiding problems which should not be hidden. As one member of the MDA panel at the recent JavaZone conference put it: "I don't want to care if my service is using EJB, COM or WebServices. I just want it to work". And MDA may make it "work", except these different technologies have vastly different runtime characteristics, so trying to treat them as "implementation details" may be productive in the short-term but incredibly dangerous in the long term.

    So, to be clear, my reference to "absurdity" does not relate to MDA evangelists believing that MDA will increase off-shore development, but rather that MDA-developed systems using off-shore developers will be of as high quality as a "regularly developed" application. That's wishful thinking, and a one way ticket to la-la land.
  141. I think CompuWare qualifies as "MDA evangelists", and the article is pretty clear on how they see it increasing the productivity of off-shore development teams.

    *sigh*

    CompuWare is indeed an MDA evangelist. CompuWare's article made no mention of labor globalization. Instead the domestic matter of "migrating development staff to ... more efficient forms of development" was the focus of the article. Globalization is your own bugaboo, and not something recognized by MDA insiders as symptomatic of generative automation.

    CompuWare's article claims that the "development efficiency" of model compilation reduces time to market, increases productivity, and solves "skill shortages". You saw that mention of "skill shortages" and presumably misunderstood it to mean that MDA somehow aids globalization. What you still seem not to understand is that innexpensive foreign talent and generative automation are substitutes and therefore competitors. MDA offers management an alternative to looking overseas for extra talent, and sadly this means that more core development will stay in Amerika.

    My concern is that this can create systems which are hiding problems which should not be hidden.

    Apparently your FUD about MDA isn't limited to labor politics. Now you're claiming that automated architecture hides bugs! This proves that you don't know what your ranting about. Experts have a saying that model compilation "leaks like a seive" when it has architectural bugs. Ie, MDA doesn't hide architectural bugs.

    So, to be clear, my reference to "absurdity" does not relate to MDA evangelists believing that MDA will increase off-shore development, but rather that MDA-developed systems using off-shore developers will be of as high quality as a "regularly developed" application.

    A sensible clarification. But again, no MDA insider has ever claimed that modeling (or any other aspect of business analysis) is easily globalized.
  142. CompuWare is indeed an MDA evangelist. CompuWare's article made no mention of labor globalization. Instead the domestic matter of "migrating development staff to ... more efficient forms of development" was the focus of the article.

    I work for Compuware, helping to evangelize their OptimalJ product. I can tell you that increased developer productivity is definitely part of our core messaging and for good reason. Brian is also correct that another major point of emphasis is that OptimalJ allows developers to focus on modeling and developing business logic instead of having to worry about how to implement a bunch of complex, syntactically demanding "plumbing" code. I can further add that, as far as I am personally concerned, I am positioning our tool, which does fully implement MDA, but more so, is a model-driven, pattern-based development tool, as a viable alternative to more drastic ways of reducing development costs, including off-shoring.

    I think Rickard says some interesting, valuable things and I have no interest in personally challenging him. I do agree with Brian that the (rather dated) press notice from Compuware he cited doesn't support any of his claims about MDA proponents (at least not *my* MDA proponents) talking about marginalizing developers. I don't want to marginalize developers. I used to be a developer. I want to give them better tools so they can do their jobs better and faster (and so maybe more of them can keep their jobs). And I definitely think Brian "gets it".
  143. What you still seem not to understand is that innexpensive foreign talent and

    > generative automation are substitutes and therefore competitors.

    Right, that is a good point. Again, the part of the blog entry you are referring to are not my own beliefs, but is the summary of what I had found in the MDA articles I had read.

    > My concern is that this can create systems which are hiding problems which
    > should not be hidden.

    >
    > Apparently your FUD about MDA isn't limited to labor politics. Now you're
    > claiming that automated architecture hides bugs!

    I'm saying it makes it easy to shoot oneself in the foot if one is not aware of the implications of the architectures used in the transformations. And my understanding of both CompuWare presentations and people who want to use it is that they indeed want to ignore such issues, which in my opinion shouldn't be ignored. Just an observation.

    > A sensible clarification. But again, no MDA insider has ever claimed that
    > modeling (or any other aspect of business analysis) is easily globalized.

    This proves that you are just ranting for the sake of it, because obviously you cannot know that no MDA insider has ever claimed that.
  144. I'm saying it makes it easy to shoot oneself in the foot if one is not aware of the implications of the architectures used in the transformations. And my understanding of both CompuWare presentations and people who want to use it is that they indeed want to ignore such issues, which in my opinion shouldn't be ignored. Just an observation.

    Thanks for bring this up; it allows me to allay a common misconception about OptimalJ. OptimalJ automates model transformations by applying patterns. Out-of-the-box, we provide default patterns, both to transform the PIM (we call ours the Domain Model) to the PSM (Application Model) and to generate the Code Model from the PSM (Application Model). But with OptimalJ you can edit and/or author your own patterns and completely override the default transformations and well as the generated code, if you like! You can even edit parts of a pattern, so you can extend or override any of our out-of-the-box patterns or any part of those patterns. And we even preserve your patterns when you update to a subsequent release of OptimalJ. Plus, of course, we never "step on" any code you add to enhance the generated code (outside the pattern editing/authoring capability, you can also add your own Java code to the generated source code).

    Since you feel obliged to use Compuware as an example of an MDA vendor, I feel obliged to make sure everyone understands the nature and power of OptimalJ. It's model-driven, pattern-based development and it's completely customizable, including the pattern-based model transformations and code generation processes.
  145. I'm saying it makes it easy to shoot oneself in the foot if one is not aware of the implications of the architectures used in the transformations.

    Your sentiment and reality are disjoint. Automation reduces the likelihood of mistakes.

    And my understanding of both CompuWare presentations and people who want to use it is that they indeed want to ignore such issues, which in my opinion shouldn't be ignored.

    The natural history of software development has been entirely one of progressively accumulating abstraction. Cognitive load drags on developer productivity, and this jeopardizes deadlines and quality. Abstraction is crucial if business descriptions are to be captured on time and with fidelity.

    Another benefit of abstraction is that it enables executable models, a revolutionary concept that allows simulation prior to implementation and integration. I simulated a model before compiling it, and this allowed me to formally isolate analysis bugs before the CASE vendor had even delivered us the code generator. I used no knowledge of the implementation technology (C++ and pSOS), and still I was able to expose subtle logic defects that otherwise would have required coding, burning firmware, reserving lab time, and then intervening with an in-circuit emulator. Our shop was certified CMM level 3 by SEI, which was an exceptional distinction back in 1995, the veritable dark ages.