.NET 2.0 Tools Evaluation- DSL, GAT, SQL 2005, Mobile 5, VSTS, Enterprise Library, Reporting Services, etc.

With the new releases pouring out of Microsoft at lightning speed it has been quit an effort to take it all in. Evaluating them for their current potential use now is quite a task. I am actively evaluating the following for the current project I am on for potential use. Below is how they are standing up...


This list has been updated here.


Domain-Specific Language (DSL) Tools - DONE - Going with UML. DSL's have a great potential if used by the right people for the right things. Currently this would be a great overhead. In the future DSL's may serve a purpose in allowing a visual representation to configuring our product, but only after it has been institutionalized as a product, we are experts in DSL, and DSL tools from Microsoft have proven their effectiveness in the software engineering field.
See http://realworldsa.blogspot.com/2005/12/vsts2005-dsl-and-software-architecture.html

Software Factories- DONE - Too far off in the future for too much consideration. The core practice does involve Product Line Engineering, so in the future we may be able to migrate over. This would include taking advantage of DSL.

Guidance Automation Toolkit- DONE- This will work great for restrictive development in the application development cycles, and for configuration of the core asset library.
See http://realworldsa.blogspot.com/2005/12/guidance-automation-toolkit-gat.html

Composite UI Application Block- ON GOING/Looking Good - This is a very thorough application block, but it will take some time and some proof of concepts to ensure it's usability. It will also have to conform to our architecture. The team that worked on this block is providing great information on the block.
See http://realworldsa.blogspot.com/2005/12/smart-client-composite-ui-application.html

Enterprise Library .NET 2.0 release- ON GOING/Looking Good - This will come in handy for many of our core components if we find it a good fit for our PLE architecture.

SQL Server 2005 Mobile Edition- ON GOING/Looking Good - Excellent integration for design purposes into VSTS and SQL Manager

Microsoft SQL Server 2005 Mobile Edition 3.0 Merge Replication - ON GOING/Looking Bad - We need to heavily test merge replication. Although merge replication has a great potential for minimizing the amount of development done in resolving concurrency issues with the database, it has proved itself overly complicated and not dependable with previous applications. The development effort would not have taken much more effort than it did to resolve all the issues merge replication introduced, if not less effort. We are also opening up the doors to databases other than SQL for future releases, so merge replication may need to be avoided.

Visual Studio Team System Suite - ON GOING - It will benefit all of us to have access to all versions of the new team system suite. We are all going to be fulfilling the role of architect, developer, and tester during the creation of the product line implementation. I do not think we have a choice but to go with the suite.

SQL Server 2005- ON GOING/Looking Good - Just using and testing. This version's manager rocks compared to 2000.

Web Services Enhancements 3.0 for .NET - ON GOING/Looking Good - The current releases for 2003 add great value for smart client development, so there is no reason to suspect the 2005 release will not add as much value. Currently one of the new features in WSE 3.0 allows for a new compression protocol for transferring binary files that greatly improves performance, so this will help with the use of transfers of our log files off of the mobile devices.

Visual Studio Team Foundation Server - NOT STARTED - A possible replacement for the vault and an integration tool for project management.

Reporting Services - NOT STARTED/Looking Good - This will serve as a replacement to Crystal Reports which is currently being used. As mature as SQL 2000 Reporting Services were upon release there is no reason to not accept this change, especially for customers using SQL 2005 or for that mater users that use SQL 2000 which allows for free use of SQL Reporting Services with their SQL Server License.

Mobile 5.0 - ON GOING/Looking Good - Mobile 5.0 has a lot of great enhancements. They way the mobile market moves forward, we don't have much choice but to use Mobile 5.0.

Smart Client: Composite UI Application Block Hands On Labs

I have just started playing around with the Composite UI Application Block Hands On Labs from the Microsoft Patterns & Practices Team. They have done a great job on this Application Block, and these labs are very well put together.

If you are doing smart client applications I suggest grabbing the labs. It is a quick way to get up speed on the Block.

Composite UI Application Block Downloads here.

Guidance Automation Toolkit (GAT), Architectural Description Document, Architectural Synthesis, Restrictive Development, and Product Line Engineering

The Guidance Automation Toolkit (GAT) has potential to be a very useful tool, especially if the organization is willing to make the upfront investment in an Architectural Driven Development process or a Product Line Engineering (PLE) process. It may provide usefulness in other processes with lower ceremony also, but the overhead of implementing it may not be allowed for in such processes. Not that it couldn't be, but the $$$'s for time are usually not allowed for by most organizations when doing one-off development, or other low ceremony projects.

Let's start by defining what we are talking about.

Guidance Automation Toolkit (GAT)-
The Guidance Automation Toolkit is an extension to Visual Studio 2005 that allows architects to author rich, integrated user experiences for reusable assets including frameworks, components and patterns. The resulting Guidance Packages are composed of templates, wizards and recipes, which help developers build solutions in a way consistent with the architecture guidance. From: http://msdn.microsoft.com/vstudio/teamsystem/workshop/gat/

Architectural Description Document-
I am not referring to Architectural Description Languages (ADLs), I am referring to a document that provides viewpoints and perspectives that are used to drive the architectural definition process. From: http://www.viewpoints-and-perspectives.info/index.php?page=library
Read more from this link to gain an understanding of what I am referring to by an Architectural Description Document.

Architectural Synthesis-
This is a production level Proof-of-Concept. It is a scaled down version of your application's architecture that includes all the pain points you find. By pain points I mean anything questionable found during your architectural definition process. The difference between a Proof-of-Concept and an Architectural Synthesis is that the later is most, if not all production level code, and a Proof-of-Concept is throw away code. An Architectural Synthesis provides a base of code with all the pain points and the implementation patterns implemented for the development teams to reference and use.

Restrictive Development-
This is an architects way of propagating the architectural constraints and patterns they want implemented through the analysis, design, and construction phase of the process. This is how they insure their quality attribute expectations are met throughout the process. A patterns catalog, including a pattern relationship diagram and code samples, for the architecture should be included in the Architectural Description Document, and they all should be implemented in the Architectural Synthesis. Developers are restricted to using these patterns when they need to implement functionality the patterns address. I plan to elaborate on this topic in a later Blog.

Product Line Engineering (PLE)-
A software product line (SPL) is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. From: http://www.sei.cmu.edu/productlines/index.html

The GAT has the potential for providing the SPL application developer with an application architecture and providing that architecture with the constraint's implementation defined by the restrictive development patterns put in place during the Architectural Synthesis.

The following is directly out of the Microsoft's GAT help file:

Your company has developed Web services that can access both local and remote business logic. The Web services are exposed to internal and external clients through Web service interfaces. You want to define an application architecture that standardizes the development of these services. The architecture has the following properties:

• It prescribes a structure and architectural constraints for new applications implementing services.
• It is designed to be used across multiple business applications.
• It prescribes the use of reusable components and frameworks in the context of the architecture.

You want to create integrated user experience that simplifies adherence to your architectural guidelines.

Scenario Goals
You want to use the features of the Guidance Automation Toolkit to simplify and clarify the following processes:

• Starting a new application that complies with the architecture
• Adding new business logic and reusable components to work within the constraints of the architecture

Implementing User Experience with Guidance Automation Toolkit
To meet the stated goals, you develop a Guidance Package that consists of a number of recipes, wizards and templates. The Guidance Package meets the scenario goals in the following ways:
Starting a new application that complies with the architecture
Adding new business logic and reusable components that work within the constraints of the architecture

Starting a New Application that Complies with the Architecture
You write a solution template that creates the recommended structure of an application for developing new services. The application has solution folders and projects for Web Service interfaces, business actions that implement those interfaces, and service gateways that actions use to communicate with other services. The template places unbound recipe references and template references in the solution. The template also defines bound recipe references and template references that, along with unbound references, help the developer with repetitive tasks such as creating messages or implementing new business actions.

Adding New Business Logic and Reusable Components that Work Within the Constraints of the Architecture
The recipes and templates associated with the solution guide the developer through the routine tasks of developing business actions and exposing their logic through Web Services. To assist your developers, you create the following recipes and templates:

• A message-defining recipe that creates a message class and associates a custom tool with it. The tool uses an XSD utility to generate an XML schema for the class. This recipe can be designed as a recurring bound recipe associated with the solution folder that hosts projects with messages. The recipe would include a project as an argument, placing the generated message class in that project. Alternatively the recipe can be defined as an unbound reference, associating itself with a project in the solution folder.
• A business action template that creates a project for a business action and unfolds a class template for the action. The recipe associated with the template collects the project name, business action name, namespace for the class, and the input and output message classes. The template is a bound template, associated with the solution folder created for the business actions.
• A recipe to add a Web service for the business action to an existing Web service project. The recipe generates a new ASMX file and class with a method that is a façade to the business action method.
  © 2005 Microsoft Corporation. All rights reserved
  

The GAT does have a learning curve, and the implementation of a Guidance Package of substantial size will require management to allot the time needed to do so, but for companies already investing in making re-usable architectures for a SPL, the time will be worth it.

The Process Ladder- UP, RUP, EUP, PLE, & Never Neverland

I have had the experience to work in one shop that did XP, and did it for real. It was a small shop with a very, very, sharp team. Communication was constant, and short meetings were happening all the time. TDD was really TDD and not just tests written after they were done coding the modules for regression testing purposes. Pair programming was a way of life. It was fast paced and the adrenaline levels had to be kept high. Documentation was created, Agile Modeling was used, and it was an awesome sight to see. After seeing that way of doing things however, I know that most development shops can not pull it off. The skill sets are not available, and management doesn't provide the tools needed to create such an environment. Plus there are very few project managers with the skill sets available that can run such a shop.

Most shops I go into do not have an industry standard process like the UP, SCRUM, or the RUP. When asked about their process they default to saying they are an agile development shop using XP. Well, in reality they are developing by the seat of their pants and have absolutely no development process. They are living in Never Neverland. They do the task list presented to them at the beginning of the day or week, and next day or week figure out what that task list broke in other areas of the application. Patch all that up over the next few days or weeks, and then start on their next task list. It works for them because they have never been exposed to any other way of doing things. Many of them have had bad experiences with industry standard development processes and they have written them off as fairy tales, or textbook processes. Good for learning about, ok to market with, but they don't believe they really work.

A lot of these places with no process will lay claim to having their own home brewed process that they came up with during the dotcom boom when every company was doing that. Companies were thrust into software development without knowing that was even what they were doing. You will usually find a page or two describing their process on their web site at a very high level, with a few colorful images with loops and arrows. If however you go into the company and ask to see their documented process, they will have nothing more to show you, or they will pull a dusty fat binder off the shelf with a ton of post-its sticking out of it that say, needs completed.

There is hope for such places. I have had the opportunity to move several development shops out of Never Neverland into a real world process. The type of projects the company wins contracts for will determine the process to which you will want to move to on the process ladder. You also need the skill sets of the team members to change as you move up the ladder, or you need to change the team members. A lot of educating is involved with these climbs, as well as a lot of un-educating. In other words, getting teams to forget the way things were done in the past.

Keep in mind that a development process is NOT a one and done deal. Every project should start with the planning of the process that will be instanced for a given project. Meaning that there will be different levels of ceremony for every project, there may be different team member experience levels, the projects will always be different, and the process should be shaped to the individual projects. Anyone that tells you one process instance is used for all their projects is telling you that to build a tree house, a 4 bedroom home, a shopping mall, and a hospital, can all be done by the same team, with the same resources, the same effort, and the same amount of planning. They are living in Never Neverland.

So with that said, I want to make sure that the process ladder diagram below is understood. The different levels of process are levels at which processes are performed, but each project would always get a new instance of a process. The current move I am taking a company through is from Seat of your pants development to Product Line Engineering (PLE). A very big transition that is going to take a long time, a lot of educating and training, and a large upfront investment of time and money.



Image 1: Process Ladder (Shift Click Image for Larger View)

SharePoint Team Site
One tool I found to be valuable during these process implementations is SharePoint. SharePoint makes a good tool for a development team repository. For every project I put together a team portal. It houses our process definition, asset templates, work spaces for individual workflows that are part of the process, discussions, and educational resources for team members.

Process Definition:
A visual representation of our process along with detailed information that explains the different workflows of the process.

Asset Templates:
These are housed in Document Libraries. The different Document Libraries included templates for such items as Business Analysis Assets, Architectural Assets, Analysis and Design Assets, Development Assets, Testing Assets, Project Planning Assets, and Estimation Assets. They are arranged and housed according to the process phases.

Each of these Document Libraries include guidelines for the use of the assets they house.

As we move into different workflows, sub sites will be created. The same structure of the Document Libraries are used, but they house completed assets for that particular workflow.

Work spaces for individual workflows:
These are used by different individuals that are filling the roles assigned to that workflow and are working on assets produced by that workflow. This is were they keep completed assets for the rest of the team to access them.

Discussions
These are used at the top level site and the sub sites (individual workflows) to maintain on going discussion about the current activities. This is much easier than following email threads.

Educational Resources:
There will be a lot of things that will need to learned depending on the experience of different team members. This area contains links to learning resources, white papers, videos, and other things to help them get familiar with it.

This takes a lot of effort to put together, but the ROI is always well worth it. New developers to the team can become quickly educated on the process and where we are with it. It also helps with educating the companies current developers, managers, marketing team, and sales team on where the company is headed.

Open Source Projects & Code Generation Tools

I am constantly being approach by members of management and other team members to consider using Open Source Projects & Code Generation tools to reduce our development effort.

When I say Open Source projects I am not referring to open source tools like Nant, FxCop, WebServiceStudio, Nunit, Fitnesse, BugTracker.NET, Reflector, Ndoc, Paint.NET, or any other tools like these. I am talking about CSLA.NET, .NET Pet Shop, .net Tiers, DotNetNuke, and open source projects that are meant to provide you with plug-in parts of your architecture that are code ready, and advertise only small code tweaks are needed.

I am not opposed to using Open Source Projects & Code Generation tools as long as they do not create more work in other areas than they promise to accomplish in the areas they reduce work in. I am a firm believer in reusing assets that are available. I do not believe "it must be built here to be used". But I have seen to many people look at Open Source Projects & Code Generation tools as shortcuts. Shortcuts are something I am always opposed to. Shortcuts to me equal either laziness, or a shortsighted budget focus. It usually indicates the person can not see the big picture, they only see the small one right in front of them.

In lower ceremony projects they usually can offer some advantages. But that is only if they benefit the entire process. That means that they are also capable of handling updates, handle maintenance, handle customization, handle testing, and handle all these things gracefully. Most of what I have had the experience to see, did not handle any of these things gracefully. They also must have a low learning curve. I have seen teams spend more time learning how to use these types of tools than it would have taken them to design it, document it, and code it themselves.

For prototypes I think they work great, if you already know how to use them. Just like all the wizards in Visual Studio we use to slap together something for demonstration purposes. But the mess the wizards and generation tools make are usually not production level code.

For Product Line Engineering the Open Source Projects & Code Generation tools must also provide the assets that are critical to PLE projects. That includes detailed documentation on their design, their architecture, performance metrics, tests, and any other details provided by a good COTS candidate. These assets then must be re-worked to fit into your process. Getting these tools into a PLE process is usually more work than it is worth. You also have to consider the fact that the part of your PLE architecture you plan to use these on, are now dependent on them, as with any other COTS product. So you better be sure they are well established.

In all situations the Open Source Projects & Code Generation has to be a good fit for your architecture. I have seen teams spend tons of time tweaking the projects and code to make them semi-fit there architecture, just so they could say they successfully pulled off their idea of using the Open Source Projects & Code Generation tools. When in reality it was a flop when you consider the amount of time they spent on getting to the point they could say it worked. And when this happens they have usually damaged the architecture.

I am not totally opposed to using Open Source Projects & Code Generation tools, and I can see they have come a long way. You should always include a lot of research time upfront to make sure you are getting a good fit for your project if you are considering going this route.

You have to make sure you are not making your architecture fit the Open Source Projects & Code Generation tools. In my book they either are a good fit all around or they are not. The benefits must outweigh the costs. Keeping in mind saving development time is not the only benefit. This is a very shortsighted view of their benefits and will usually get you in trouble. Just saving development time is not a good enough reason. You have to consider the overall process, every phase. I have seen the Open Source Projects & Code Generation Tools really burn a lot of maintenance phases, testing phases, and completely trash subsequent releases.

Open Source Projects & Code Generation tools always need a higher degree of management and constraints around their use. If this doesn't happen, then they usually only cause headaches.

The one I have used and will continue to use as long as the quality remains the same is the Enterprise Library from Microsoft. They provide sample, great documentation, and tests.

Project Management with Limited Resources

Sometimes you just have to figure out how to make do with what you are given. Today the 5 person team I was promised to build my project turned into a one person team. So I had to use my project management skills to figure out what to do. Simple, make the most of what you are given.

One little email to the one team member left and we are back on track…..

Email….

It looks like it will be you and me building all of the core framework. Starting Jan. 3rd you’ll be on a 24 hour schedule. You can take a nap every 6 hours for thirty minutes, you can eat anytime as long as you have someone bring it to your desk, your family can visit you for 1 hour on Sundays between 6am and 8am, your family can call you once a day for up to 5 minutes, we will put a portable toilet in the cube next to you so you don’t have to walk to far to the bathroom, please make arrangements for a dry cleaner to pick up and drop off your clothes once a week.

Any questions?

SOA and ESB buzz...

SOA and ESB are the newest buzzwords in the industry for the same patterns that has existed for years in good architectures. Most businesses do not, and will never understand that. Yes, there are new technologies available for implementing them, but the patterns are the same.

We can't ignore the fact that businesses are now embracing these new ways of describing parts of good architecture. Actually I find it a blessing in disguise. Although I know neither are silver bullets, and both must be used in the proper context and within the scope to which they lend value, to me it is like any Patterns catalog. The market place has simply classified and named common patterns and made them available to the public.

At least I now stand a better chance of having the executive across the table understand what I am talking about if I am describing an architecture that includes SOA and ESB buzz words.

.NET Software Engineering versus .NET Software Development

I have worked with a lot of great one-off development shops. Shops that reuse whatever they have available in the code library that is reusable to build new applications from. One of the hardest things to do is change the mind set of management and the development teams from one of software development to one of software engineering. Is there a difference?

Engineering is the difference. When I worked as an Electronic Engineer I was introduce to the engineering field. I believe that insight is what gives me the patience to accept engineering in software development. The engineering killer in our current market is "time to market". Well actually it is the perception that time to market brings to the table. Most shops believe the sooner code is being written for production the closer they are to being finished. Never mind performance, maintainability, reliably, security, and the rest of the quality attributes. Any shortcuts they can find in the design and analysis process are perceived to be an asset.

In engineering 80% of the effort is found in the documentation, the planning, the proof of concept testing, architecture verification and validation, and analysis and design. Don't get me wrong here, one too many documents developed during the process that wasn't needed to describe the application was wasted time. 20% of the time is put into developing a well designed application.

In one-off development it is the reverse, 20% of the time is spend doing the documentation, the planning, the proof of concept testing, architecture verification and validation, and analysis and design, and 80% of the time is spent developing (30% percent of which is spend debugging and shifting code design).

What most shops don't realize is that doing engineering correctly provides much more reusable code (it is cleaner and can be found easier), an application that is much easier to maintain and update, and an application with a lot less bugs, that performs better, and is much more secure. Engineering also provides the possibility of creating a reusable process that contains the metrics to do estimations instead of guess-tamations.

Not every shop should do software engineering. They may not be able to hire people with the skills required to pull it off because they aren't making applications that produce that type of revenue. They may have gurus (and they are paying enough to keep them on forever) who prefer agile development and they are producing high quality applications without the need for software engineering. They just don't want to. It's a shame, but "we just don't want to" is what I hear the most. They say they have been doing development like this since the dot com boom, then during their big layoff period, and now that they are stabilized once again, they see no need to change.

The problem that they don't see is that their development tools have changed. They are no longer scripting, or using VB 6.0 to crank out overnight applications. They are now using a fully capable OO/Component-oriented programming environment. To ignore this fact leads to worse spaghetti code in .NET applications, than it did in ASP2.0/3.0. Without engineering, you also loose the capability to take advantage of patterns correctly.

Will this Blog change anything out there? Doubtful, but it was something to type until Fear Factor started……

Generics, Patterns, and Software Architecture

Generics are going to lend themselves well to the implementation of software patterns at all levels. Whether it be at a code design level, application architecture, or application integration level. We will find a lot of instances of using object in the past in our designs, we will want to refactor into the use of generics.

I have not had the opportunity to use them until now. I am embarking on a proof of concept on which I plan on using them at different levels of abstraction. So then what is the point of this Blog? Just to let you know I have had time to investigate the resources I will be using and wanted to share them. Both are excellent in their coverage of Generics. More will come later as I work through the POC.

Professional .NET 2.0 Generics
http://www.amazon.com/gp/product/customer-reviews/0764559885/ref=cm_cr_dp_pt/104-4875122-0369527?%5Fencoding=UTF8&n=283155&s=books

Foundations of Object-Oriented Programming Using .NET 2.0 Patterns
http://www.amazon.com/gp/product/1590595408/qid=1134422548/sr=1-1/ref=sr_1_1/104-4875122-0369527?s=books&v=glance&n=283155

Where is my Project Manager?

One of the biggest threats I have found on most projects, is the lack of a skilled project manager. As an Architect I am asked to assume this role a lot by default. Leading the development team and doing project management are not the same thing, and I am not a good project manager. Most companies I have worked with do not understand the roles of the Software Architect or the Project Manager, and they try to group them into the same role and call them a Technical Project Manager. The same is true of the Lead Developer and the Project Manager, they try to group them into the same role.

I think one of the things that keep companies from understanding the role of a project manager is that a project manager does not produce many tangible artifacts. When they are allowed to do their jobs properly they may produce project schedules and task lists, but that is about it. The rest of the time they are coordinating their team members activities, communicating with management, marketing, external customers, and internal customers. They are their team's first line of defense from being pulled off their scheduled task by management, marketing, external customers, and internal customers. They are also the one who ensures that deadlines are met by their team.

The Project Manager knows what is going on with every stakeholder on the project and are ensuring the communications between them are being handle effectively and efficiently. They are the Software Architect's biggest ally when they are doing their jobs correctly, and their biggest enemy when they are unqualified to do the job.

I have never seen a successful Technical Project Manager. They have either fallen behind in the technology, or they are still up to speed with technology and have no clue what project management is. They believe it's creating a very detailed project plan and then giving the marching orders. They are usually never good at keeping the communication channels running smoothly.

A lot of consulting firms like to throw their account managers (basically sales men) into the role of project manager. This always has a terrible effect on the project. They are usually not technically savvy and they have very little if any management skills. They stop by the project once or twice a week to check on the team, and to see if his lead developer is managing the project for him to their customer's satisfaction.

Any large scale high ceremony project must have a good project manager on board for it to succeed. Delivery does not = success. I define success as being delivered on time, within budget, and having a solution that is easily maintainable and updatable.

A good project manager is hard to find. They are just good managers in any given situation, whether it is in the software industry, customer service, or the restaurant business. They are usually a natural at it. I would rather work with a good project manager that has zero technical background, than a Technical Project Manager that has no clue how to keep the communication channels running smoothly. A project manager with good managing skills will trust their architect or lead developer to handle the technical decisions, so they don't need to be technically savvy. They also have a natural knack for reading people and can quickly tell when someone isn't qualified to be on their team or is blowing smoke.

Having been on over 20 projects I have seen 2-3 good project managers that I myself would hire. I will let you guess on how many out of those 20 projects we were forced to say delivery = success.

Valuable .NET Architect and Developer Links

Every project includes a resource of links to help educate the team on parts of the process they may need to learn. Here is the latest set of links I compiled
http://www.corporatewebbing.com/rwsa/links.htm

VSTS2005, DSL, and Software Architecture

VSTS 2005 offers nothing but Visio in the way of tools to the Software Architect. There are plenty of tools for the System Architect, Developer, Tester, and Project manager, but banks everything on DSLs and Software Factories for the Software Architect. Both will add some value in the future, but the only tool we have to work with now is UML 1.4 in Visio AGAIN, which they say they have no plans to upgrade. The MSF agile templates so far are horrible, and our process we are putting together is a Product Line Engineering (PLE) process that uses off shore development, so the process's ceremony is very high. We need heavy documentation to produce an effective communication channel between our Marketing/Management team, Architecture team, and our Development Team. We are currently widdling down the RUP to UP, and then building it up to a PLE process on our own. So we are creating 70% of the artifact templates and guidelines by hand.

I put this out a few weeks ago after evaluating their DSL toolkits:

I think every yahoo in the world who likes to re-invent the wheel will be putting out their own designers. This now ticks me off as much as the MSF did when it claimed to be a process framework when it first came out. The only thing that has accomplished is making a huge mess, and then coming back full circle when they decided to give it some instances of structure, and they implement XP, UP, and RUP. The same processes that were around when they started their mess.

We have worked far too hard to get where we are with industry standards for software development. Why is it the electronic engineering field has been able to stabilize? I doubt they would have if they would have engineers defining their own schematic language on every project across the world.

Imagine being a consultant and every new gig you get you walk into you need to learn a new modeling language. I think DSLs can add value if they are used correctly, but UML already does when used correctly.

The only part of it I like is the template engine, but this isn’t going to be worth the mess this makes.

The only hope we have is if the experts in the field like Mr. Booch, Mr. Gamma, Mr. Martin, Mr. Ambler, Mr. Jacobson, Mr. Gomaa, Mr. Clements, Mrs. Northrop, Mr. Fowler, Mr. Evans… etc. (You know who you are) step in and take the lead on this, to get this under control as quickly as possible, and guide us in the right direction on how to use this correctly. Then and only then will this possibly stand a chance of just not making a huge mess.

We need someone at MS to produce a MSF template mirroring the UP (the only process I have seen be truly successful in a non-agile environment), and if they are banking on Product Line Engineering (PLE) as there core process for Software Factories, we need an MSF process Mirroring what SEI combined with the ITEA projects says PLE is. There is already a company working on getting a MSF RUP template to work within the VSTS environment.

Along with these processes that are intended to document the architecture (software architecture, not system architecture), they need to provide the modeling tools and process templates that make implementing them possible.

MS needs to get on the ball as to what Software Architecture is and what we need to be successful, so far VSTS 2005 is greatly lacking.