Microsoft's software factories and UML rejection

Discussions

News: Microsoft's software factories and UML rejection

  1. Microsoft's software factories and UML rejection (32 messages)

    Grady Booch explains why he disagrees with Microsoft's rejection of the UML in favor of proprietary domain-specific languages and his thoughts on Software factories.

    Microsoft's conveyor belt methods for software are dead wrong, witless, and counter-effective. Organizations that build good software know that software is an R&D activity, not a production line just-in-time effort.

    Grady Booch explains why he disagrees with Microsoft's rejection of the UML in favor of proprietary domain-specific languages and his thoughts on Software factories.

    Threaded Messages (32)

  2. Grady Booch explains why he disagrees with Microsoft's rejection of the UML in favor of proprietary domain-specific languages and his thoughts on Software factories.

    I never thought I'd see the day that Microsoft would go public with rejection of an open standard in favor of a proprietary approach.

    ;-) (Yes I know, it's obvious humor - it's a salty Friday morning though)
  3. Microsoft always had embraced open standards (initially), but then they start to tweak it and make it more propietary, it's their way to lock you into their technology.
  4. Remember Objectory?[ Go to top ]

    Didn't Ivar Jacobson - one of Grady Booch's amigos - develop a methodology (and write a book about the lite version) called "Objectory" which supported the notion of a software factory (object-factory)?

    I wonder what Ivar would say about Microsoft's use of the "software factory" metaphor?

    Cheers,
    Ashley Aitken.
  5. Software factories, name souns little right. Its beyond patterns and UML. MDA is just in air, sounds like named by one person -- not team, its sounds like i have Nut and Bolt, what do you want to make. Companies like Ford, or BMW will laugh at it.

    Ok What is software factories? -- It brings XML into picture to define Data and (domain) process. That is to say Data and Context.

    Go Deep, bring on Patterns. Now we have -- Data, Context, Patterns, ie. to say i have cement, bricks, and i have blue print (ie i want kitchen, i want 3 bath, i want a big back yard) --- an idea to live better, so that i can grow somethings in my back yard without worrying about space, and Context is how much money i have.

    This sounds realistic then --- most of companies flatly rejecting to build any UML diagram of their system, which earns revenue for them.

    Cann't reject, need more time to see how it comes up.
  6. There are some very good reasons to use OpenOffice.org instead of Microsoft Office, and the best reasons have nothing to do with cost of the software.

    Although I have regularly used Microsoft Office in the past, I haven't even had it installed on my system for over a year. This is despite completing a thesis, working with legal documents, exchanging business documents, writing academic papers for publishing as well as creating software based presentations.

    I have NOT needed MS Office to do any of these things. OpenOffice.org is adequate - it has all the essential features, including style list functions for real publishing, document comparison capabilities and import/export abilities, a capable spreadsheet, and a presentation program that does its job while importing and exporting PowerPoint.

    But it's not just that OpenOffice.org is "adequate" for the job. As a software developer and long time computer user, I think OpenOffice.org is superior in several important respects. I would like to describe these points, because I think that others will also understand the issues better when they recognize the implications for themselves:

        *

          OpenOffice.org runs on multiple platforms. Currently: Windows, Linux, Solaris, FreeBSD, Mac OS X. This is important because I use several operating systems, including Linux. It is a huge advantage for me to be able to work on the same documents under the same interface whether I have booted Linux, Windows, or whether I am using a thin Solaris workstation.
        *

          OpenOffice.org is stable, and runs smoothly. It has not crashed on me under Windows or Linux, and does not do wacky things. MS Word has scared me in the past with some of its flaky behaviour.
        *

          I trust the OpenOffice.org software and its developers; I may even contribute to the project myself! The office suite is open source, and the Internet community is heavily involved with improving Sun's original software. You're guaranteed to never experience licensing-related hassles (expired licenses, product registrations, lost keys, forced updates) which have occasionally caused much aggravation and lost productivity for MS Office users.
        *

          Data longevity: this is an important point, which is often overlooked because it's really only an issue in the (distant?) future. Microsoft has made it clear that it wants proprietary document formats, and inconsistent ones at that. This may work as long as Microsoft is around and developing software that supports files created by outdated products. Personally, I'm more comfortable with my OpenOffice.org documents in XML format because I know that in the worst case scenario, I can unzip the document structure and easily extract text from the XML components. This is technical, but what it comes down to is: my data is easily accessible in the future. It is also easy for third party developers to write tools for OpenOffice documents.
        *

          Data interchange: this builds on the previous point. MS uses proprietary document formats and seems unwilling to allow seamless data flow between different software from independent vendors. It's just not in their best interest. OpenOffice.org uses data formats designed to be easily interchanged (OASIS specification), and other projects are cooperating with the vision of open document interchange - e.g. Abiword, and KOffice.
        *

          Now, given the rapid worldwide growth and popularity of open source software, including OpenOffice.org, do you really think you're better off locking your documents into an inflexible, non-interchangeable format (MS Word version X)? I would argue that for anyone who values document longevity and interchange, it's in their best interest to use software based on open data formats.

    After all: software companies die, but information lasts forever. If a company takes the secrets of unlocking your data to its grave, where will that leave you?

    http://www.pc-tools.net/comment/openoffice/

    Firefox is better than M$ crappy IE

    http://spreadfirefox.com/
  7. As with everything, it's a bit shortsighted to discard any alternative solution .. I think there's quite of a lot of interest in DSLs, especially in the fields of system engineering, logistics, etc.. where UML is too difficult and heavy to describe you processes. The thing is that you'll have to define your own DSL metamodel for each different area/project.

    I do agree with using UML for J2EE applications in particular since the UML model elements can closely be mapped onto domain elements such as entities, services and client/server process flows.

    At the end it boils down to one thing: "What is the most simple, straightforward and effective way to communicate you architectural/design ideas into a formal and unambiguous computer language ?"

    Personally I expect many more of these tools to popup in the near future .. this being Microsoft's answer to OMG's MDA.

    -- Wouter
  8. It’s all about lock in[ Go to top ]

    AndroMDA already generates J2EE applications and I once saw .Net on their to do list. The result would be a UML/OCL model that could generate work alike applications in both .Net and J2EE. Other MDA tools will, in the next year or two, achieve this as well.

    Of course Grady Booch wants platform independent models and of course Bill Gates doesn’t. His motive for Domain Specific Languages instead of UML is the same as C# instead of Java, .Net instead of J2EE, and COM instead of CORBA.

    Just as Sun and others had to implement Java on Windows, model transformations for .Net will be left to third parties leaving Microsoft free to further lock in their foolish customers.
  9. Why do you oppose UML and DSL ?[ Go to top ]

    His motive for Domain Specific Languages instead of UML

    I do not understand why do you people oppose UML and DSL ?
    First of all UML is not a programming lanuage at all. Of course you can generate some sceleton code out of UML. But you can also generate code of ВЫДб not just java or c#
    DSL is ortogonal to graphical modeling. It is programmers tool, not designers or architects.
    You should talk DSL vs OO libraries, not DSL vs UML.
  10. Why do you oppose UML and DSL ?[ Go to top ]

    But you can also generate code of ВЫДб not just java or c#
    should read "But you can also generate code of DSL not just java or c#"
  11. The reason why[ Go to top ]

    Whence UML is seen as a programing langage it is logical to compare at the same level.
    The same kind of misunderstanding occurs when UML is restricted to OO approaches.

    Remy
  12. Maybe DSL cann't do UML's job now[ Go to top ]

    I think MicroSoft don't know what does the Enterprise level developers want,they don't have exerprience in this field.So DSL cann't replace the position of UML, but maybe the DSL 1.0 or 2.0 is ugly,then DSL 3.0 or 4.0 become perfect,for example the Directx and the VB.
  13. Guys, guys, don't fight. UML 2.0 and Software Factories are BOTH bloated, impractical approaches for translating diverse business requirements into robust, maintainable software. In a way, each of you are winners.
  14. sorry for the misunderstanding, just wanted to make a generic comment

    anyway, I have been using MDA on my 4 most recent (J2EE) projects and I must say that UML is extremely useful and not heavy at all for the translation of a 3-tier architecture into maintainable code (for the record, I'm using UML 1.4 not 2.0)

    I agree there's a lot in both UML 1.x and the new 2.0, but I just take those things I think are useful to me. Why exactly do you think it is bloated ?

    -- Wouter

    FYI: I have been using/developing AndroMDA (www.andromda.org), works just fine for EJB/Spring/Hibernate/Struts/...
  15. +1
  16. Microsoft did nothing new[ Go to top ]

    Until now, microsoft still has less experience at enterprise level. The software factory is not something new. They always show you how fast to build an academic project with their new technologies(normally some reuse components). This time, they just make things a little complex. I don't think their products and concepts will serve enterprise level if they still hold the faith of software evolution for dummy developers.

    Jim
  17. Microsoft did nothing new[ Go to top ]

    Until now, microsoft still has less experience at enterprise level. The software factory is not something new.

    Everythin Microsoft will show up is *not* new. Microsoft just claims that they did a completly new invention. For example tell me, how is DSL different to GME, MetaEdit+ or MOF? They all allow one to create a metamodel for a specific domain.

    If you are interested in Meta-/Domain-Specific Modeling you may also take a look at the OpenSoul Metamodeler project. A project that is based on MOF/MDR.
  18. Parabole of the blind[ Go to top ]

    From the beginning UML has been set as a modeling language, and that qualification is arguably the main factor in its success.
    Regarding Development Processes, there should be some alternative between bureaucratic (RUP) and acrobatic (Agile, XP, etc) approaches.
    Nobody will build bridges with creativity alone, yet bricks are not as pliable as bits. So there should be hope.
    As a matter of fact, the constituents for the design of lean and clean processes are already available, what is needed is a shift in paradigm:
    - Development semantics (development flows) vs Model semantics (code generation)
    - Bottom-up (from flows) vs Top-down (one-fits-all) processes
  19. I mostly agree with Mr. Booch opinions. Also some other posters in this thread (Wouter, Daniel).

    But anyway this is typical MS. Comparisons:

    1. J2EE Platform = OS independent vs. .NET Platform (theoretically OS independent with MONO) = but mostly Windows dependent.

    2. Now, instead of MOF and UML, they are doing their own "Meta-Modeling" and "Modeling" Language. Everybody can surely define their own DSL (and this is a very good approach) but you can still use standards like MOF and UML to define your own DSL. No problem with this (= lightweight and/or heavyweight extension of UML). Just what Mr. Booch already said or what AndroMDA has already done with their "cartridges".

    What does this mean to us?
    -> We need MS tools to work with their DSL. We cannot use standard UML tools => dependency to MS.

    Anyway, this is how business works, you cannot just agree with each others, it would be very boring ;-)

    Greets,
    Lofi
    http://ejosa.sourceforge.net
  20. <cite> lightweight and/or heavyweight extension of UML ?? </cite>

    Its like saying -- Desktops and Server are ....lightweight and/or heavyweight extensions of Mainframe...

    Grady works for IBM, and Microsoft is proposing software factories.

    Same thing repeating, can you reject any one of them?, which one has made life simpler? Better? Distributed?
    Network computing?
  21. Sorry to be unclear :-)

    1. Lightweight extension of UML means, you use UML profile which consists of Stereotypes, Tagged Values and Constraints.

    2. Heavyweight extension of UML means, you use MOF to extend the UML metamodel itself.

    Mostly you combine both techniques to create your own language -> DSL -> Domain Specific Language.

    So, you cannot say that it's impossible to have your own DSL with UML and MOF... This is what Mr. Booch tried to say :-)

    I recommend everyone to read the very nice MDA book from Mr. David S. Frankel "MDA: Applying MDA to Enterprise Computing" which has a very deep view to this topic.

    Thanks,
    Lofi.
  22. Much of the frustration with MDA comes from the confusion between models and programs.
    While MDA should establish a principled framework for a differenciated management of representations (analysis), specifications (designs), and implementations, most of the current works go the other way and discard any conceptual basis for such a distinction.

    Remy
  23. DSL to the rescue of MDA[ Go to top ]

    I don’t think that the use of a DSL in itself should count as a rejection of UML. Actually, I think that DSLs are an enabler for any realistically sized application of MDA.

    UML can be applied more or less out-of-the box for certain types of modeling tasks. For other modeling tasks, defining a suitable UML profile (or UML meta model even) is a development task in itself. Especially for models that are intended to capture a business’ intellectual property (and much less, engineering details), the UML profiles do turn out very complex indeed. Developing such profiles is a very specialized activity; do not think that a developer reasonably skilled in UML can be trusted with this. More worryingly, the UML profile and the semantics it represents may turn out to be very abstract and alien to analysts and domain experts (which are the ones to fill the model after all!).

    Applying a DSL over such a complex profile certainly can alleviate the latter problem. With a DSL, complex modeling semantics can be presented (graphically, or otherwise) in a way that is natural to domain experts. For example, an ERD-like DSL will appeal to a DBA (who does not sit well with UML), while a Petri Net-based DSL is very much suitable to modeling processes and work flow. With the proper tooling, the information thus captured is transferred to the UML profile where it can be processed by the UML-based MDA tool chain.

    Of course, having to invent one or more DSL’s for your project as well as having to implement tools for them is not really appealing. The use of an “universal language” for instantiating specific DSL’s is explored in this papper: http://www.cs.chalmers.se/~tveldhui/papers/2004/dissertation.pdf. Interesting stuff...!

    \Ron
  24. DSL to the rescue of MDA[ Go to top ]

    What a strange rescuer ...
    MDA is supposed to abstract from domain specific requirements in order to deal with architectural considerations and development patterns. DSL do the opposite.
    Remy
  25. Microsoft are not the only ones who believe there are fundamental problems with MDA and another approach is needed.

    Martin Fowler is skeptical: http://martinfowler.com/bliki/ModelDrivenArchitecture.html

    Scott Ambler is skeptical:
    http://www.sdmagazine.com/documents/s=826/sdm0406e/
    http://www.sdmagazine.com/documents/s=6977/sdmam1203/

    Personally I believe Domain Specific Languages offer a number of advantages. First though let me clarify what I mean by Domain Specific Languages.

    Domain-specific languages were historically identified as complete programming languages, each
    having its own grammars, compilers, and so forth — what we call one-off languages.

    The reality is we are already using many domain specific languages and new ones are emerging all the time. I consider SQL, EJBQL, HQL, JDOQL and XPath to be domain specific languages.

    Creating a usable domain specific language of this kind is onerous as you need to develop a grammar and a parser of some kind in order to use it. Projects like javacc make this easier but it still beyond most people.

    XML however changes all of that.

    AspectJ is a DSL for describing aspects. It is of the traditional language type using a grammar, parser and compiler. AspectWerkz, JBossAop and Spring are all AOP languages implemented using XML.

    In his article Grady says "XML is not really for human consumption" I think that is true of XMI but not XML in general.

    I consider Struts config files a DSL for describing MVC-2 web applications. I consider Hibernate mapping files a DSL for describing Object-relational mappings. Many developers are quite comfortable editing these files by hand. It is much nicer to use a Stuts graphical editor. Theoretically you could develop a set of stereotypes to model this using UML but it is not nearly as easy to use a graphicl Struts editor and a text editor worked just fine for several years.

    Granted an XML based DSL is not as readable as a

    Ultimately this is where MDA is doomed in my opinion. The prescribed way of creating DSL's with MDA is using MOF and there are only a handful of people on the planet who are capable of that and even then none of the MDA tool support code generation from a custom DSL implemented using MOF.

    Grady states "MDD is all about raising the level of abstraction for the developer" and I couldn't agree more. UML is great for representing class diagrams and object models. Getting your application design in captured in an implementation independent form is hugely valuable. However MDA has failed miserably to provide a way to model one of the most important assets of a software application - the user interface.

    UML is great form modelling the Model and Controller part of the MVC pattern but provides no way to model the View. There is no OMG standard for modelling the view. What do I mean by modelling the view? Check out the XUL challenge - http://xul.sourceforge.net/counter.html
    Here are a plethora of DSL's for describing a user interface - most of which are quite readable and all of which have a way of viewing the language graphically - the view.

    The MDA choice is to create a custom DSL using MOF or to simply not model the view. That is what all MDA vendors do right now - they choose NOT to model the view - so one of the most valuable assets of a software application has no platform independent model. For this alone DSL's offer promise.

    Benj Fayle
  26. <quote>
    Creating a usable domain specific language of this kind is onerous as you need to develop a grammar and a parser of some kind in order to use it. Projects like javacc make this easier but it still beyond most people.
    </quote>

    yes, indeed :-)

    <quote>
    XML however changes all of that.
    </quote>

    yes, and why not XMI?

    <quote>
    Ultimately this is where MDA is doomed in my opinion. The prescribed way of creating DSL's with MDA is using MOF and there are only a handful of people on the planet who are capable of that and even then none of the MDA tool support code generation from a custom DSL implemented using MOF.
    </quote>

    Not agree with this. Don't forget UML Profile ("lightweigt extension of UML"). See my thread above.

    <quote>
    UML is great form modelling the Model and Controller part of the MVC pattern but provides no way to model the View. There is no OMG standard for modelling the view. What do I mean by modelling the view? Check out the XUL challenge - http://xul.sourceforge.net/counter.html
    Here are a plethora of DSL's for describing a user interface - most of which are quite readable and all of which have a way of viewing the language graphically - the view.
    </quote>

    Still you can use UML for this purpose, I don't see any problem. Surely it won't be so nice if you compare it with a "real" graphical representation of a GUI builder, but you can do this. UML does not tell you anything about the representation of the language.

    I would say, today in the time where we have a *lot* of *XML schemas* all over places (you said this by yourself :-)), it is wise to move to one schema we all can agree with => XMI. This is why we have a "Meta-Metamodel" level (MOF), to describe the "Metamodel" level and this is typical in Computer Science. To handle complexity we need to go one abstraction layer higher!

    Why? Reuse, reuse and reuse ;-)

    Cheers,
    Lofi.
    http://ejosa.sourceforge.net
  27. DSL to the rescue of UML[ Go to top ]

    What a strange interpretation of MDA...

    As I interpret it, MDA is nothing more than the long established idea of separating the specification of a system (“how”) from the details of the way that system uses the capabilities of its intended technology platform (“what”).

    So in MDA:
    - Business requirements are captured free from any implementation bias
    - The design concerns of a realizing platform are captured independently too

    Capturing the business requirements using UML is hard to do. Either the resulting model is not precise enough or the UML profile/meta model has made things so complicated that analysts and (non-IT) domain experts wouldn’t know how to apply it.

    I’m strongly in favor of using a DSL (or a Domain Specific *Modeling* Language, to be exact) to precisely capture the business requirements in a manner that appeals to analysts and domain experts.

    \Ron
  28. DSL to the rescue of UML[ Go to top ]

    Well, that would wash if, and only if:
    1 - Requirements could be defined once, fully, and finally before any commitment were made to the project.
    2 - Requirements could be defined independently of architectures.
    Such assumptions can (sometimes) be verified for standalone projects but are completely irrealistic for large projects in distributed system with legacy applications.
    Remy
  29. DSL to the rescue of UML[ Go to top ]

    The discussion at hand is whether a DSL might actually be more suitable for capturing domain knowledge than an UML-based modeling language. I don’t see how this discussion is in any way influenced by these requirements being captured in one go (or not) or being independent of architecture (or not).

    \Ron
  30. Control Freaks[ Go to top ]

    Whilst many of the arguments presented in this thread in support of one technology or another have their pros and cons what is nevertheless evident is that debate, as usual, rallys around two camps - Microsoft on one side and everybody else (IBM, OMG, Sun, Java Community, etc) on the other side. We could call the latter camp "The reasonably open community".

    I have just finished reading Steve Cook's article at http://www.bptrends.com/publicationfiles/01-04%20COL%20Dom%20Spec%20Modeling%20Frankel-Cook.pdf
    in which he raises many objections about MDA, UML, MOF, and even OMG. These seem to have raised Grady Booch's (bless him) hackles. Regardless of the merits of the arguments what underlies it all for me are the following points about Microsoft's views:

    1. We don't like the UML, etc. We've got better ideas on doing things and these will become evident in time when we release our products. These wonderful ideas will extract the really useful parts of UML, etc, and build on them. This is classic FUD.

    2. Rally round the Microsoft way of doing things and you too will have a better life as a developer, analyst, manager, etc.

    3. Buy Visual Studio which will contain every whiz-bang you could ever wish for, for building those killer enterprise apps. This, BTW, from a company with no proven track record in enterprise computing.

    If Microsoft think their ideas are better why don't they just join the rest of the open community in improving things. Is it because if you collaborate you lose control. Are their ideas really so superior as to be worth spending billions developing in isolation or are they just control freaks who believe they must always be in charge? This could be a pathological condition.

    Microsoft will as usual go the proprietary route. They've done this with .NET and C# which are supposed to be better J2EE and Java. Even if they are were they really worth the effort?

    Microsoft do come up with goods ideas - they may not be good innovators but there is no doubt that they are good improvers. What remains for open community to do is to appropriate these good ideas. "They feed of us so we too will feed off them". By this mutual feeding process we get approximate equalization of products and processes. Users then have a choice - buy into proprietary Microsoft products (and lock-in) or go the open community way.

    For the open community to thrive and to be kept on its toes it needs Microsoft to thrive (but, please, not too well).
  31. Linux advocates have long insisted that open-source development results in better and more secure software. Now they have statistics to back up their claims.

    According to a four-year analysis of the 5.7 million lines of Linux source code conducted by five Stanford University computer science researchers, the Linux kernel programming code is better and more secure than the programming code of most proprietary software.
    * Story Tools
    [Print story] [E-mail story]
    * See also

        * Sun Dabbles in Open Source
        * SCO Says Microsoft Memo Is Legit
        * Linux Takes on the Windows Look
        * Novell Gives Linux a Big Hug
        * News from the Linux front

    * Today's Top 5 Stories

        * Linux: Fewer Bugs Than Rivals
        * Lamprey May Offer Paralysis Cure
        * Chess Conspiracy Unconvincing
        * Oil Eaters Slurp Up Spills
        * The Library of Google
        * Wired News RSS Feeds

    Tech Jobs Partner
    Today's the Day.

    The report, set to be released on Tuesday, states that the 2.6 Linux production kernel, shipped with software from Red Hat, Novell and other major Linux software vendors, contains 985 bugs in 5.7 million lines of code, well below the industry average for commercial enterprise software. Windows XP, by comparison, contains about 40 million lines of code, with new bugs found on a frequent basis.

    Commercial software typically has 20 to 30 bugs for every 1,000 lines of code, according to Carnegie Mellon University's CyLab Sustainable Computing Consortium. This would be equivalent to 114,000 to 171,000 bugs in 5.7 million lines of code.

    The study identified 0.17 bugs per 1,000 lines of code in the Linux kernel. Of the 985 bugs identified, 627 were in critical parts of the kernel. Another 569 could cause a system crash, 100 were security holes, and 33 of the bugs could result in less-than-optimal system performance.

    Seth Hallem, CEO of Coverity, a provider of source-code analysis, noted that the majority of the bugs documented in the study have already been fixed by members of the open-source development community.

    "Our findings show that Linux contains an extremely low defect rate and is evidence of the strong security of Linux," said Hallem. "Many security holes in software are the result of software bugs that can be eliminated with good programming processes."

    The Linux source-code analysis project started in 2000 at the Stanford University Computer Science Research Center as part of a large research initiative to improve core software engineering processes in the software industry.

    The initiative now continues at Coverity, a software engineering startup that now employs the five researchers who conducted the study. Coverity said it intends to start providing Linux bug analysis reports on a regular basis and will make a summary of the results freely available to the Linux development community.

    "This is a benefit to the Linux development community, and we appreciate Coverity's efforts to help us improve the security and stability of Linux," said Andrew Morton, lead Linux kernel maintainer. Morton said developers have already addressed the top-priority bugs uncovered in the study.


    http://www.wired.com/news/linux/0,1411,66022,00.html?tw=wn_tophead_1
  32. After this post and a post about OpenOffice I can't resist any longer:

    All your base are belong to us ... You have no chance to survive make your *POINT*!
  33. One of Mr. Booch's main points is:
     
    <quote>
    I'm disappointed that Microsoft choose the term "software factory," because it's an emotionally-laden phrase that harkens to extremely mature manufacturing methods that focus on stamping out endless copies of the same thing, although perhaps with slight variants therein.... Tom Demarco in his book Why Does Software Cost So Much? sets aside a chapter on software factories in which he notes - and I agree with him - that "I think factory methods for software are dead wrong, witless, and counter-effective. Organizations that build good software know that software is an R&D activity, not a production activity. Organizations that try to make it into a production activity produce bad software (though potentially lots of it).
    </quote>
     
    This argument contends that all apects of building systems is creative to the point that software factories cannot accomodate the level of variance between systems. This argument is fundamentally flawed, as evidenced by the prevalence of established design patterns.
     
    I would argue that companies building good software actually want to take creativity out of the development process when it comes to components for which mature design patterns exist. In other words, the building blocks should come from software factories and be assembled in a creative way to solve the problem at hand. Only the truly unique components should be hand-crafted.