VSTA, the enterprise architect and the application lifecycle

There are a many types of architects in an organization and one of them is the enterprise architect, he / she architect’s enterprises. So, what do they do and how can ALM benefit from their work? Very brief they make ICT valuable and adoptable for the business, they are the bridge between business strategy and the ICT of an organization. When looking at the ALM circle I would say they feed the business part. Not very well explained, they better can do it their self… you can find here on wiki and here on DYA some more information.


One important thing for application lifecycle management are the artifacts they deliver to the overall process and products? What kinds of tools are used? And how can the application lifecycle benefit from it, so projects can work in a more collaborative way with the ivory tower. [ouch, I think they don’t like that word]

IBM just acquired Telematica which has a tool System Architect. This tool specially made for enterprise architects and positioned by Gartner as the lead tool in the quadrant for enterprise architect tooling gives a nice overview of the work of enterprise architects.

So, some screenshots from the five minute demo.   

tele10 tele8 tele9


This is a little bit chaotic model, but it explains the dependency between the business, the applications/ components and infrastructure.

Each of these layers can be modeled separately in System Architect. for example the structure of the business.

The Logical Data Model

and some Business Process Modeling with swim lanes and the ability to make use cases from it.

So, enterprise architects have / make an overview of the complete business structure, business processes, the relations with infrastructure and software components. Which give them the capability to make decisions about what software components / applications should be made to support the business, which actors have a place in this process and with which other components does this new component / application communicate [have a dependency] with. Beside this, also information about hardware / infrastructure, datamodels and ideas how all this should evolve in the future. [I’m not talking about standards and guidelines, that’s a complete different discussion]

How should development use this information created by enterprise architects?
First of all, if they do their work well, it helps the development department to work on autonomous, loosely coupled projects, that can be managed and executed in isolation, with no dependency on other projects. So you don’t get any deadlocks when one project isn’t finished yet. More practical, the development department can define separate team projects in Team Foundation Server in place of having to put all the project in one Team Project [that's a nice trigger for a bad definition of projects].
The other important part is helping re-use or better stop the re-creation of services/ components which already are made and offer the right [or almost right] functionality. Having an overview of all the software components and the business processes that uses them should help the definition of services and which software component uses it, so having this information available in projects will stop the recreation of this functionality.

More at project level, the actors are already defined even business use cases are already made [generated] so it should be interesting to re-use [import] those in Visual Studio Team Architect, for further modeling of detailed use cases and activity diagrams. With enterprise architecture in place project shouldn’t great their own actor definitions and business uses cases, even external components and their interfaces can be re-used by designers and solution architects.


Get the information in Visual Studio Team Architect.
CaptureThe best place in VSTA to have this information available, is within the Model Explorer. No predefined sets of actors and use cases for the whole enterprise [that only would make a mess of re-use] but only for one specific project the specific actors, business use cases and external interfaces. Cameron has a nice overview of the model explorer on his blog The UML Model Explorer. I have to mention he uses new bits so not all functionality can be found in the current CTP.

Creating an addin which imports the information from System Architect, Visio or any other enterprise architect tool [even the heavy used tool powerpoint should be possible :-) ] into the model explorer is very easy. The ‘shapes’ available in the model explorer are described in an XML file called “ModelDefinition.uml” adding the necessary xml to this file will show the shapes in the model explorer, ready for further modeling.
For example the XML below is the XML from the shapes shown in the model explorer showed on the left.


How can enterprise architects benefit from development and operations?
It’s for sure a two way communication, it’s even a collaborative effort between operations, development and enterprise architects to work on the enterprise architecture process [and application lifecycle]. The first thing I think when I see all the fancy ‘high level’ diagrams with connections, dependencies and the evolution made by enterprise architecture, is that they never ever represent the real world. The models are made, projects are defines and implemented over time, new projects are added, models are updated… at solution architecture level there is already a challenge to keep models up to date / in sync with the running code. So, having these higher level models representing the real world is even a harder job. But development can help, with the architecture explorer in place we can visualize the real world, even what .NET framework is used and what kind of external components. Interesting information for enterprise architecture to check their models, an import or export should be possible, I think…


On the other side operations can give enterprise architecture additional information about application uses, is a component not used? or by people in a different business process as they thought it would be… when we want to deliver this kind of information back to enterprise architecture we sure have to in cooperate ‘design for operations’ in the architecture [enterprise and solution architecture].

Anyway, interesting thoughts. Have to work and discuss this much deeper to get a good insight in the collaboration between enterprise architecture and Application Lifecycle Management but that there is a tight connection that's for sure.

Comments (7) -

so this is it, well this a good plan,

What a cool and original blog post, I enjoyed hearing your thought leadership on this topic.

what a great info, thanks.

very nice info sir, thank you very much.

thanks for this nice info, it's so useful for me.

Business is not possible without communication. it is the backbone of every business

Add comment

Şarkı Sozleri