VincentH on .NET

Steve Cook just announced that he is moving to the VSTS Architect Edition team, to work with Cameron Skinner building UML tools for Rosario on top of the DSL Tools. As you may recall, we can expect these five UML 2.1 diagram implementations in Rosario, built on top of the DSL toolkit:

• Class Diagram
• Use Case Diagram
• Component Diagram
• Sequence Diagram
• Activity Diagram

The fact that these are built on top of the DSL toolkit may provide interesting integration options with additional DSLs, e.g. if we can use the “Designer Bus” (a.k.a. “backplane”) for that (see the Software Factories in Rosario CTP post series by Edward Bakker for details: part 3, part 4 and part 5).

Stuart Kent gives some more hints in this post about interesting integration and extensibility options for these designers:

“Worth calling out are the features to allow a designer to be extended with new metadata once it has been deployed, and support for designers and models to interact. This will allow the designers delivered by Team Architect to be extended, and for new, third party DSLs to interact with them. Both these are key aspects of connecting UML with DSLs in the UML + DSL story that Cameron speaks about.”

I’m happy with this design decision by MS.

I like an approach that enables pragmatic solutions today while still moving toward the overall Factories vision. In realizing the factories vision at Macaw with the Macaw Solutions Factory, we use this type of pragmatic approach all the time, and it works great for us. I even think that such an approach is necessary if you ever want to actually arrive at the full vision (see my post on Factories 2.0).

It looks more and more like the Rosario release will really bring modeling to the masses, this will provide a lot more added value for the VSTS Architect Edition.

In the most significant post on factories to come out of Microsoft in a long time, Jack Greenfield unveils Software Factories 2.0. The software factories initiative has been repositioned within Microsoft to address a larger scope:

“Perhaps the most significant change is that the leadership of the Software Factory Initiative has moved from the Visual Studio Team Architect team to the Developer and Platform Evangelism (DPE) Platform Architecture Team. This move was designed to broaden the scope of the initiative”

Some of the things that now come into scope for the Microsoft Factories Initiative:

• “Leverage Microsoft products such as InfoPath and SharePoint“ This is a good thing! At Macaw, we designed the Macaw Solutions Factory to target all Microsoft server products right from the start. This proved to deliver much more value (for us as a systems integrator) than more common factories that focus mainly on modeling and code generation for (parts of) the .NET framework.

  Especially targeting SharePoint (WSS and MOSS) deployment and ALM aspects has provided great value for us, since this is a very challenging product in these area’s. Jack is not specific about whether “Leverage” means using these products to implement the factory itself and/or targeting solutions built on top of these products. I hope it will be both, of course.

• “integrating Software Factories with Software-plus-Services (S+S) Blueprints“
  Michael Lehman, who developed the project GlidePath infrastructure that underpins the existing blueprints, has recently moved to Jack’s new team. This will be an interesting marriage to watch!
  Jezz Santos mentions in “Factories & BluePrints – TechEd 2008” that Michael has already grabbed all Factories slots at TechEd Orlando, he seems to be moving fast.
• SOA Think Oslo…

And much, much more… which brings me to the next point:

Will “Larger” mean “Later”?
When you work on realizing the factories vision, as I have been doing with the Knowledge Development team at Macaw for some years now, one of the main challenges you have to deal with is scope.

Realizing the factories vision is most effective if you combine all aspects of the vision (think of the four pillars of software factories). If you have a company-wide initiative, your scope will eventually include all solutions technology as well as all people realizing solutions. Of these two, people require the bigger part of the effort [getting them to use and enhance the factory]. At least, this is what happened at Macaw.

Fortunately, at Macaw we were the right size of company to target our entire primary process (realizing IT solutions based on Microsoft technology) with one comprehensive factory initiative when we started. No “seperate kingdoms” of unaligned initiatives that we could not conquer had evolved – yet. We were lucky to be at the right place, at the right time, with the right idea.

Why am I telling all this? Because I recognize some of the same developments in this repositioning of the factories intiative at Microsoft. Microsoft moves to include more technology and - even more important- more people in their initiative. The move to DPE seems logical and even necessary. The “people” dimension of the scope at Microsoft is truly staggering, though. Which translates to very large efforts and very big inertia.

The real challenge in this Microsoft initiative will be to balance agility (regularly delivering tangible results that are most useful right now) with integration (aligning many Microsoft groups, products and initiatives to the right degree) and durability (earlier results not being invalidated by next steps). Because the factories vision takes such a long time to fully realize, a good balance on these three aspects is essential to both sustain the initiative and to actually arrive at the full vision.

If you misbalance, you run the risk to either fizzle out (lose momentum with people by taking too long – agility), disintegrate (collapse into a mess because directions of people and technologies are too disparate), or never reach your goal (one step forward, two steps back if next steps invalidate earlier efforts in the same initiative).

So is this factories thing a long shot?

In my opinion Microsoft is doing the right thing with this move, but you should appreciate that this initiative will take a long time to come close to realizing the full vision.

Does this mean that we should wait 10 years until all of this arrives? Definitely not, because significant benefits can be realized with what can be done today!

What I learned while working on Macaw’s factory initiative is that most important for progress and value is not substantial factory foundation technologies, but the core factory concepts and the mind shift of people that are both the factory users and it’s innovators: the people building IT solutions every day.

In my experience you can implement factory concepts with relatively light investments, using simple, existing Microsoft technology, today (more details on that in a later post). The real effort and time – but also value – is in the change in people’s mindset.

Strategy

Realizing the factories vision as a systems integrator can have a redefining effect. To realize a factories initiative and to get full benefits from it though, it needs to be a core part of the company strategy. This way, the technology, users, innovators as well as the business model all are guided to reap the very significant benefits. Building factories is not just about building a development tool…

We really are transforming the way IT solutions are being developed. When the industrial age of software development has arrived, will your company be part of it? Will your people have internalized the new paradigm? Will your business model allow you to maximize profit?

Will you be a factories 2.0 company? If you want to, my advice is - take your time: not in waiting for it, but to realize it. With the people and business model in place using current technology, you will be able to quickly leverage new factory foundation technology as Microsoft delivers on the vision, increasing your lead on competitors even further.