ALM Definitions
Always interesting what the different organizations say about a topic.
The coordination of development life-cycle activities, including requirements, modeling, development, build, and testing, through:
- enforcement of processes that span these activities;
- management of relationships between development artifacts used or produced by these activities; and
- reporting on progress of the development effort as a whole.
Source: The Changing Face of Application Life-cycle Management - Forrester August 2006
Application lifecycle management (ALM) regards the process of delivering software as a continuously repeating cycle of inter-related steps: definition, design, development, testing, deployment and management. Each of these steps needs to be carefully monitored and controlled.
Source: Wikipedia, the free encyclopedia
Application Lifecycle Management (ALM) aligns the three capabilities of the organization: Business, Development and Operations by providing integration between the various tools used and activities performed within each of these capabilities.
Aligning these three capabilities results in applications that meet business demands and that are better manageable.
The Three pillars of ALM
- Traceability
- Process automation
- Reporting and analytics
Manual processes can be more efficient and effective through tool integration
Source: Application Lifecycle Management and Visual Studio Team System WorkShop [no link]
and don't forget Borland...
Borland believes every CIO and IT organization deserve the infrastructure that empowers them to advance their software delivery process by making it measurable, predictable and improvable, just like any other critical business process. And, we fight for the rights of our customers who are passionate about driving the next generation of software productivity on their terms.
Source: Open Application Lifecycle Management (ALM) Vision
What can we learn from these definitions?
A wide variety in scope. ITIL is focused on the operational side of ALM, the Wiki and Forrester descriptions are more focused on the Software Development Lifecycle [SDLC] and Microsoft takes a bigger scope with business, development and operations, although the tooling and the assessment are focused on SDLC. Borland is also talking about a wider scope, when you look at the RUP like model. But the main pro is their focus on "many processes and many tools" so it should fit more then one environment.
Beside this difference in scope, everybody agrees on terms like: measurable, predictable, traceable, manageable, monitored etc etc... smells like "in control" ;-)
Anyway, I use this image when I define ALM and for sure it's about "in control" but it's even more about communication..! the people, helping them to communicate in a seamless manner.
How To Fire a Guidance Package Recipe from the Implement Application Feature of Team Architect.
Post #01 of a collection of posts with some more technical details about the creation of richer implementations with Visual Studio Team Architect.
The Start: Fire a Recipe, Wizard or something else when initiating the "Implement Application" feature from the Application Diagram.
There is only one place where you can change the behavior of this feature and that is in the properties window of the selected shape. You can change the the template it uses to implement the application. Select: "Custom Template..."
So, we have to focus on templates [vstemplate] if we want something else to happen.
Beside the fundamental elements "TemplateData" and "TemplateContent" where you can specify the files included in the template and categorizes the template, there is also an element "WizardExtension" which can be used to run custom code and more things like: "Display custom UI that collects user input to parameterize the template" and "Add parameter values to use in the template", actually you can perform virtually any action allowed by the Visual Studio automation object model on a project.
To use this element is easy, create a assembly which implements the IWizard interface, sign it and add it's details to the vstemplate WizardExtension element.
The IWizard interface gives us a number of methods which will fire during the execution of the template. For example:
public void RunFinished()
public void RunStarted
(
object automationObject,
System.Collections.Generic.Dictionary<string, string> replacementsDictionary,
WizardRunKind runKind,
object[] customParams
)
You can get additional information from the replacementsDictionary parameter and can add information to it.
So, with this information you can start with coding your additions to the template, add solution folders, add projects, add items, add code. The first solution I created, to accomplish a richer implementation then the "Empty Web Site" template offers, used a list of item templates in the "TemplateContent" element. But, after the solution went bigger and I wanted to do more this didn't gave me the flexibility I needed. So, the final solution ended with only the WizardExtension which executed all the necessary steps, from project creation to adding code with the CodeDOM and references. You only have to take the DTE Object and start coding...
// The application object can be cast to the root DTE object.
dte = (EnvDTE80.DTE2)(automationObject);
sol = (EnvDTE80.Solution2)dte.Solution;
To use the IWizard interface, DTE object and the CodeDOM is pretty hard, actually it really hurts and it's not suitable to make such a big customization to your templates, for small ones it's works fine but not for this size.
So, the release of the Guidance Automation Toolkit for Orcas made things much easier.
Guidance Packages also use the "WizardExtension" element behind templates to execute additional logic as you can see in this XML snippet.
<WizardExtension>
<Assembly>Microsoft.Practices.RecipeFramework.VisualStudio, Version=1.0.60429.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a</Assembly>
<FullClassName>Microsoft.Practices.RecipeFramework.VisualStudio.Templates.UnfoldTemplate</FullClassName>
</WizardExtension>
When you dive into the "UnfoldTemplate" class you can see it also inherits the IWizard interface. So, things should work the same. Only with the GAX you get the ability to use T4 templates and all the other functionality like actions and recipes.
In the vstemplate there is the element "WizardData" which points to the recipe it executes during the unfoldtemplate action and with that you can use basic GAX functionality to create your projects.
<WizardData>
<Template xmlns="http://schemas.microsoft.com/pag/gax-template"
SchemaVersion="1.0"
Recipe="CreateSolution">
<References/>
</Template>
</WizardData>
So changing the Service Factory Modeling Edition or creating your own package starts with some customizations in this recipe, because we don't [I don't] want to see a wizard when initiating the implement application feature.
<Arguments>
<Argument Name="SolutionName">
<Converter Type="Microsoft.Practices.RecipeFramework.Library.Converters.RegexMatchStringConverter,
Microsoft.Practices.RecipeFramework.Library"
Expression="[a-zA-Z][a-zA-Z_0-9]*(\.[a-zA-Z][a-zA-Z_0-9]*)*"/>
<ValueProvider Type="Evaluator" Expression="$(safeprojectname)"/>
</Argument>
</Arguments>
<Actions>
<Action Name="CreateModelProject"
Type="Microsoft.Practices.ServiceFactory.CustomRecipes.CreateModelProject.CreateModelProjectAction,
Microsoft.Practices.ServiceFactory.GuidancePackage">
<Input Name="SolutionName" RecipeArgument="SolutionName"/>
</Action>
</Actions>
The argument captures the current selected [on the application diagram] projectname and the "CreateModelProject" action unfolds the model project template. Pointing to this changed / newly created vstemplate with in the Application Diagram will fire this recipe when using the Implement Application feature.
Next post: Collect data from the Application Diagram.
Reduce Project Risk: Get knowledge of the environment where the system operates.
One of the most “technical” challenging phase of a project is the transition of code from the development environment through the integration and test environments into production with Installer Packages.
Within most companies developers are responsible for the creation of Installer Packages. The MSI’s are created on development workstations, which have local admin rights and most often some exotic settings and applications. For sure, completely different than the production environment. With all the risks and extra work during deployment and testing.
In a more ideal situation, packages are automatically generated during the build process. A much better situation, but also harder to accomplish. The process is completely automated and can be reproduced. But still it doesn’t reflect the production environment, which still result in project risks.
When development doesn’t know and can’t test against real production environment settings we get some challenging risks.
For example how should we test non-functional requirements like: availability, scalability, capacity and performance? and how should development write installation instructions and operations guides (deployment, backup, recovery, weekly tasks) and probably there will be some problems with security and the configuration of security settings when deploying to production.
So, a better way should be when development knows the production environment details.
Operations can describe every detail about the environment, but, you also can use Team Architect’s Logical Datacenter Designer [LDD].
Logical Datacenter Designer is used to create models that describe the policies and logical structure of a datacenter, including servers, firewalls, communication paths, security constraints, and other configuration requirements that affect the deployment of application systems into a datacenter.
The Logical Datacenter Designer is a design tool..! so don't tease operations with Visual Studio, you will get the most strange reactions when you do that. You better could use the IIS Settings Import Wizard and ask for the credentials.
Anyway, finally you will end with a more "in control" deployment process.
Development knows the production environment, so they can design and build there applications with the real settings in mind. With this extra knowledge Design For Operations and Design For Deployment are much more realistic. Development can give operational management the right information how the solution need to be managed and monitored which will result in lower project risks..!
Some extra things we can do to automate this, "Enable ALM by Automation":
- Generate installer packages from the Logical Datacenter Designer, System Designer and Application Designer. We've got all the information we need! [see DSL 4 WiX]
- Generate MOM packages and manageability models [see Design for Operations on Codeplex and this post]
- Create WorkItems in TFS.
- Create Threat Models with the "Import Deployment Report" feature from the Microsoft Threat Analysis and Modeling Tool and create WorkItems from there.
- ...
some additional information:
- MSDN Virtual Lab: Architecting Connected Systems: Logical Data Center
- MSDN Virtual Lab: Architecting Connected Systems: System Designer
- Kevin Sangwell Blog: Bridging the Gap between Development and Production [very good information about this topic]
- Gearing Up for Modeling, Microsoft Style, April 01-2006
Rosario Team Architect Exposed, Getting Information Out Off the Designers.
I'm not fully up and running with the Rosario CTP, but found yesterday evening some time to dig into the internals of Team Architect. [Reflector rules]
Getting information out off the designers.
It is pretty hard to iterate through the various applications and endpoints within the VS2005 and VS2008 designers . You must load the .ad file with an XML reader and query it. Rosario makes this allot easier, it exposes methods to do this.
This is the Application Designer ToolAdapter Interface with the getApplications, getEndpoints, etc methods:
The new way to iterate the applications and endpoints. Much better than overly long XML queries:
Inside the "Rosario" Service Factory there are some helper classes to get the ISoaService
Update: removed the formatted code and added screenshots.
Mini-Stories for Visual Studio Team Edition for Software Architects, Rosario CTP10
Very useful, these mini-stories founded on the CTP10 desktop
- Walkthrough: Visualizing Interaction Sequences Between Service-Oriented Applications
- Walkthrough: Designing and Visualizing Classes and Their Interactions
- Walkthrough: Building Windows Communication Foundation Web Services Using Distributed System Designers and the Web Service Software Factory (WSSF)
From the "Stories"document [the interesting topics highlighted in red]:
In this CTP, you will find many new exciting features that help make design and development more productive. These features can be grouped in to two categories: factory integration and new integrated designers.
Factory integration starts with a base design experience in Visual Studio Team Edition for Software Architects, which applies to multiple application types. We then extend this experience for specific application types (Web client, smart client, and so on) using downloadable ‘factories’ supplied by the Patterns & Practices group at Microsoft. These factories provide a guided design experience based on best practices that accelerate enterprise design and development using the Microsoft platform. A pluggable architecture allows these factories to be shipped continuously on the Web so you can continue to receive the latest design guidance between major releases of Visual Studio. In this CTP, we’ve already downloaded and installed a factory for building Web-based applications based on WCF to demonstrate one specific application type (Web Services Software Factory).
To better enable a wider range of design experiences, in this CTP we have added two new designers “in the box.” The sequence designer allows you to model the interaction of services or objects in your application. This is very useful as a design tool to help you define how your application will fulfill the requirements of your solution. Using this designer, you can identify important classes and services and make sure that they have the correct operations to support your scenarios. In addition, we have added a logical class designer to complement the existing physical class designer. This designer lets you reason about class design before committing to an implementation and enables you to model relationships not possible just by using the physical class designer. Most importantly, these two designers are integrated so that changes in one designer naturally flow to the other to keep your models synchronized and support accurate code generation and discovery in future CTPs.
So I played with it [not heavy, still quite busy with Orcas], I recreated the models from our original project
First the application designer:
I still think to many shapes that don't belong there [the red ones].
The Application Explorer:
I really like it it's called "ServiceContractDiagramViewpoint"... see this post about viewpoints.
The Sequence Designer:
I have to play a little bit more with this one... looks / works create maybe the shapes should have the same color as they have on the Application Designer [not that important].
Anyway, more details will follow...
The Three Most Interesting Features in Team Architect "Rosario"
1: The Designer Bus,
No documentation about this yet.
It makes integration of models allot easier. For example the integration between the Application Diagram and the Service Models or the Sequence Diagrams.
2: Using the Distributed System Designers and the Web Service Software Factory to build WCF applications.
Very nice :-)
There are new WSSF items in your Toolbox from where you can design services and there are parts of the Team Architect Powertool used to visualize implementation details.
I'm not a big fan of the PowerTools, a reasons is that there will be to much shapes on you design surface and classes / assemblies have a different level [lower] of abstraction than applications... I used it a for a while but stopped with it, Anyway, I give it a try in this CTP...
3: Visualizing Interaction Sequences between Service-Oriented applications.
This has some really added value when designing distributed systems..!
When you take a look at the document "Evaluating a Service-Oriented Architecture" from the SEI you can find this page, design and document a Service-Oriented Architecture with: a component and connector diagram [application diagram] and sequence diagrams...
For more details: Jeff Beehler's Blog: November Rosario CTP now available!
Download location:Visual Studio® Team System Code Name "Rosario" November 2007 CTP VPC Image
Documentation: Visual Studio Team System Code Name "Rosario" November 2007 CTP Documentation
Autonomous Develop Services for SOA Projects with Team Architect and Service Factory
In an ideal "SOA" world, business-services have a business driver or at least some one from the business who is responsible for it [knows something about the data and operations that service exposes] and has information who is consuming, is going to consume the service and who is allowed to consume. With that, takes the initiative to ask the development department to make that business-service.
The real "SOA" world: the business thinks in GUI's and not in services. So, they ask for applications and let the decision which service to make to the development department. 
That's no problem, till more and more applications are going to be build and more and more services are created.
For example the first application needs customer data. So, this project team start with the creation of a customer-service. Meanwhile an other request for an application enters the development floor, which also needs to consume customer data.
Two situations can occur:
- The project-managers from the different projects are getting a fight about who is responsible [budget] for the creation of that service. Projects will wait for each other till there is a compromise and peace. You have been chosen to be the Deadlock victim..! [I like that SQL Server message].
- The different projects both create their own customer-service. Bad, bad solution... but very common in the real world.
A solution...
It's the responsibility off the development department to define, create and deploy services, also when the business defines them it's the development department's responsibility to take control in this process.
So, what should be a solution from a development point of view.
- Make Partitioned Solution Structures..!
See "Solution Explorer" image, this is a normal solution structure. I think you can see what kind of problems we get when an other project also needs the customer-service.We got a deadlock for this project, they have to wait till this project finished the development of this service or they have to make one them self.
With a Partitioned Solution [image below and links a the bottom] you're using multiple solutions, each representing a sub-system in your application. So, each service will have his own "solution". Developers can focus on this single service-project and this service-project should have his own build and TFS project environment. So, if the business won't separate them... we do it our self!
.gif)
- Although we are making a Partitioned Solution structure, there is still a challenge left... What about projects who need that service and are also under development? this is where Team Architect can help [see image]
With Team Architect you can model your systems and define the endpoints operations and types. So, when we define all this service provider information the consumers also know what kind of operations and types they can expect. With that we can generate some basic implementations for the service agents.
What will happen when there is an other project which will consume a service in this project... just add it.
With the Service Factory we have control in which way the projects are created.
In the "Master" solution I let it create only the models and on the background it creates the "Partitioned" solutions, with the project specific models from where the development of that services can continue.
[At this moment I create for every endpoint service provider and consumer a separated model, I think this will change... for the provider "service contract" model that's fine but for the service agents I'm going to change it to one model per service instead of per endpoint]
[The solutions]
[The single service project. the good thing is that the master solution still is in control about the operations and types this service exposes, so all the agents are updated automatically]
[The service agent, which will generate a mock / stub for service in development and a real service proxy for existing services]
Still some challenges ahead but I think it's in the right direction [any comment?].
Anyway, time to look for Microsoft Visual Studio Team System code name "Rosario" November 2007 CTP, Rob Mensching just published a post that it will be released today [pacific time] and more important it will have a WiX Toolset. [good job..!]