Mike Walker's Blog

ArchiMate 2.0 Highlights

I am really excited about the new release of ArchiMate.  The reason I am so excited is that for the first time ArchiMate complements TOGAF with a compelling, versatile and unambiguous visual modeling language that covers the end to end enterprise architecture development method and not just solution architecture. Not only do we have the next evolution of the standard but it also comes backed with the training and certification aspects as well that makes this a very real and implementable standard.

This post is centered around some of the key highlights distilled from the my previous two posts (The Open Group Releases ArchiMate 2.0 , ArchiMate 2.0 Certification Released) and some additional analysis of the recent release of ArchiMate.

In general, the  ArchiMate 2.0 aids in the following ways:

• Helps model the enterprise architecture
• Works in a manner aligned with TOGAF
• Supports the preparation and management of:
• Business change
• Application rationalization
• Program and portfolio management
• Outsourcing scenarios
• Improves business and IT alignment
• Performs cost analysis and business case calculations

 

Additionally, there are six key aspect you should know about the new Archimate 2.0 specification.

 

#1 Improved and Expanded

• Based on many years of practical experience of modeling and analysis of Enterprise Architecture by a world-wide user base
• ArchiMate 2.0 now enables the creation of fully integrated models of the organization’s enterprise architecture, the motivation for it, and the programs, projects and migration paths to implement it

 

#2 Now fully aligned with TOGAF

With ArchiMate 2.0, it’s the first fully integrated version with TOGAF. With the updates of TOGAF 9.1 (clean up of the spec) and ArchiMate 2.0 we finally have a real modeling notation for EA. It promises to provide a vendor-independent set of concepts, that helps to create a consistent, integrated model “below the waterline”, which can be depicted in the form of TOGAF views.

• Integrated, consistent and coherent modeling in various phases
• Specifically designed for enterprise architecture
• Full support for viewpoints (predefined and user-defined) that supports generation of compelling views for various stakeholders from a central repository
• Not just the ‘boxes’, but also their interrelationships
• Explicit support for the service paradigm that defines business, application and infrastructure services with concrete, visible results for various stakeholders can be generated from a repository
• Impact-of-change, gap analysis, etc.
• Easy reuse of models, maintained in shared repository

 

#3 Improved TOGAF ADM alignment

• The language structure of the ArchiMate Core corresponds with the three main architectures as addressed in phases B, C & D in the TOGAF ADM
• The extensions to the Core closely correspond with the main aspects to be addressed in the Preliminary phase, Phase A and the Central Requirements management repository, as well as Phases E, F, G and H

The largest alignment area is the Architecture Metamodel as shown below:

 

However, there are great examples for each phase are shown below:

Preliminary Phase

Team Organization

 

Building Architecture Principles

 

A – Vision

Stakeholder Analysis

 

Business Goals

 

Architecture Vision

 

B – Business Architecture

Business Architecture

 

Realization of Requirements

 

C – Information Systems Architecture

Baseline / Current State Architecture

 

Target / Future State Architecture

 

Gap Analysis

 

Process Application Support

 

Information Structure View

 

Data Dissemination Diagram

 

D – Technology Architecture

Baseline Technology Architecture Model

 

Target Technology Architecture

 

Technology Architecture Gap Analysis

 

Platform Decomposition Diagram

 

Application / Technology Support Map

 

E – Opportunities and Solutions

Transition Architectures

 

F – Migration Planning

Projects for the Transitions between Plateaus

 

H & RM – Architecture Change Management & Requirements Management

Traceability Model

 

 

#4 ArchiMate 2.0 improves collaboration

By promoting a growth in shared understanding across multiple information roles including business executives, enterprise architects, systems analysts, software engineers, business process consultants and infrastructure engineers

 

#5 New Core extensions

• The Motivation extension to model stakeholders, drivers for change, business goals, principles and requirements
• The Implementation & Migration extension to support project portfolio management, gap analysis and transition and migration planning

 

#6 Inconsistencies have been removed

• Examples have been improved
• Additional text has been inserted
• Certain aspects clarified

 

 

Technorati Tags: ArchiMate,Open Group,Modeling,Enterprise Architecture

ArchiMate 2.0 Certification Released

Along side the release of the ArchiMate 2.0 specification, a new certification for the ArchiMate has been released this week.

ArchiMate, an Open Group Standard, is an open and independent modelling language for enterprise architecture that is supported by different tool vendors and consulting firms. ArchiMate provides instruments to enable enterprise architects to describe, analyze and visualize the relationships among business domains in an unambiguous way.

The ArchiMate Certification Program provides certification for people, training courses and for tools that meet The Open Group standards:

• The ArchiMate 2 Certification for People Program is a market-driven education and certification program to support ArchiMate 2, and ensures that individuals are knowledgeable about ArchiMate.
• The ArchiMate 2 Tool Certification Program ensures that a tool meets the mandatory requirements to support the ArchiMate modeling language.
• The ArchiMate 2 Accredited Training Course Program provides an assurance mark for training courses including an assessment both of the course and also the personnel and organization. In addition, all accredited training course include in their course fee the examination.

 

Resources

This section contains links to the key program documentation, including Datasheets, Policies and Conformance Requirements for each aspect of the certification program, together with the CSQ templates where applicable

 

Program Datasheets

The following datasheets are available describing the ArchiMate 2 for People Certification program.

• ArchiMate 2 Certification for People: Program Summary
• ArchiMate 2 Certification for People: ArchiMate 2 Certified

 

Certification for Individuals

• ArchiMate 2 Certification for People policy
• ArchiMate 2 Certification for People Conformance Requirements
• ArchMate 2 Certification for People Trademark License Agreement

 

Accreditation of ArchiMate 2 Training Courses

• ArchiMate 2 Training Course Accreditation Policy
• Archimate 2 Training Course Accreditation Agreement
• Archimate 2 Accreditation Trademark License Agreement
• ArchiMate 2 Training Course Accreditation Conformance Requirements
• Archimate 2 Training Course Accreditation Conformance Statement Questionnaire
• ArchiMate 2 Accreditation checklist
• ArchiMate 2 Training Course Accreditation Fees
• Requirements for IBT Examination Supervisors
• Examination Proctor Agreement
• IBT Technical Requirements
• IBT Candidate Delivery Help

 

Archimate Tool Support Certification

• Architecture Tools Certification Policy
• ArchiMate 2 Tools Conformance Requirements
• ArchiMate 2 Tools Conformance Statement Questionnaire
• ArchiMate 2 Certification and Trademark License Agreement

 

Source: http://www3.opengroup.org/certifications/archimate/

 

Technorati Tags: ArchiMate,Open Group,Enterprise Architecture,Modeling

The Open Group Releases ArchiMate 2.0

The Open Group released ArchiMate 2.0, the latest version of the organization’s open and independent modeling language for enterprise architecture. The updated version is now aligned with TOGAF, enabling enterprise architects using the language to improve the way key business and IT stakeholders collaborate and adapt to change. New certification programs for the standard will also be available for those interested in becoming certified in ArchiMate 2.0.

 

ArchiMate 2.0 will include the following features and benefits:

• Improved business and IT alignment through  enterprise architecture modeling aligned with the TOGAF ADM
• Ability to better support the preparation and management of business change, application rationalization, program and portfolio management and outsourcing scenarios
• Ability to perform cost analysis and business case calculations
• A Motivation extension to model stakeholders, drivers for change, business goals, principles and requirements
• Implementation and Migration extensions to support project portfolio management, gap analysis and transition and migration planning
• Improved consistency and examples, as well as additional clarification updates from the previous version

 

Additional Resources and More Detail

• What’s New in ArchiMate 2.0?
• Visio Stencils

Navigating through the Complexities of Architectures

A common challenge among architects and architecture organizations is the challenge of properly understanding the landscape of architecture assets within and external to the enterprise. With all the different definitions, hierarchy and levels of abstraction it can be difficult to really get your arms this problem space.

At an architecture summit were questions like:

• What is a pattern?
• Is there a difference between a reference architecture and a pattern?
• How would you classify an architecture asset?
• What is the difference or the line between architecture and implementation?

These are all great questions and I am sure there are questions asked by many others as well.

There are things you can do to alleviate this pain. Below are four activities I have used to help clear up the confusion:

• Lock on Vocabulary - A large part of the problem (not the only) is one of vocabulary. Having a common definition for these terms goes a long way. After walking through the questions above with architects what we quickly found was that we were actually deriving to the same definition but using different terms.
• Classification – As you go through the terms there will be quite a bit of iteration on the relationships of these terms. This classification or taxonomy is important to lock for your organization. It helps you understand the context and the relationships of the asset to all other things. 
• Leverage Mainstream Vocabulary and Classification – In a past experience of mine (7 or so years back) when aiding in building an Office of Enterprise Architecture we found this same issue of locking on terms we can all understand as an enterprise. We spent the better part of 6 months (in duration not effort) just trying to lock on terms. This involved passionate debates and religious wars on how people understood the space and their personal preferences. Save yourself the heartache and leverage an existing standard. It will be better for your organization in the long run.
• Provide Examples – Run through a few scenarios to exercises the vocabulary and classification system. This will accelerate the end users understanding of the concepts.

 

There has actually been quite a bit of work done in this space. The Open Group’s TOGAF 9 has defined this space really well at the macro level. This is what they call the Enterprise Continuum. There site has a lot of detail on this and you can find more on the Enterprise Continuum Online Book Chapter. 

The definition of the Enterprise Continuum is: a view of the Architecture Repository that provides methods for classifying architecture and solution artifacts as they evolve from generic Foundation Architectures to Organization-Specific Architectures

So essentially it is providing a classification and common set of definitions for the space. There is a small bit of taxonomy work here but it is inferred not in a typical taxonomy format but the outcomes are that of a taxonomy.

 

I really like that this framework accommodates real world challenges such as regulatory compliance, business change, technology disruptors and competitive forces. This is all rationalized in the context of business and IT strategy which is a first class citizen in the framework.

This is demonstrated in the diagram below when you look at the traceability aspects of the framework.

Above shows abstraction at a high-level and below is an exercised high-level architecture partitioning of the model that can be mapped to the ADM methodology. This is what makes the model actionable as it leverages the deep definition of an architecture method to make the classification implementable.

 

If you are looking to supplement TOGAF or look at other perspectives there are great resources at the OMG, IEEE, FODA, and others. Of all the sources TOGAF (in my opinion) is by far the most complete across the spectrum and is the highest used by both enterprises and tools vendors.

Another helpful piece of context setting which isn’t necessarily in the Enterprise Continuum is the notion of an Architectural Style. I talk about his in a post I wrote a couple years back in “What is an Architectural Style” . I think that this is complementary to the Enterprise Continuum as it is more of guiding principles of the Architecture and Solution Continuum.

I define an architecture style as:

An Architecture Style is a logical grouping of patterns or architecture references that is implemented through cohesive methods for solving a problem area with a unique set of concerns.

 

At the time this was a way to reduce confusion around key macro technology patterns such as SOA, now this has shifted to another amorphous concept of Cloud Computing. See below for an example:

 

Additionally, J.D. Meier has a good post on Reference Models, Reference Architectures and Reference Implementations that could be either worked into the TOGAF vocabulary but also used independently if need be.  The reason I bring this post up is that he has some good definitions that could be an alternative or provide additional context.

See J.D.’s descriptions below:

• Reference Model - A Reference model is a model of something that embodies the basic goals or ideas, and you can use it at as a reference for various purposes. It’s like holding up a diamond and looking at the different facets. It basically serves as a backdrop or canvas, or a foundation and springboard for deeper dives. They are also useful for pulling together a bird’s-eye view of a domain or problem space. A well-known example is the OSI model. Key Attributes include: abstract, entities and Relationships, technology agnostic, and they clarify things within a context. By using a model, you can focus on higher-level concepts, ideas, and decisions.
• Reference Architecture - A reference architecture provides a proven template solution for an architecture for a particular domain. It’s the high-level “blue prints” for putting the pieces of the puzzle together.
• Reference Implementation - A reference Implementation goes beyond a reference architecture and is an actual implementation. This is where the rubber meets the road and it serves as an exemplar down at the implementation level.

 

Technorati Tags: Enterprise Architecture,EA,Open Group,TOGAF,Taxonomy

What Enterprise Architects can Learn from Designers

Warren Berger from the Harvard Business Review Blogs posts a really good article titled The Four Phases of Design Thinking. he contrasts the lessons we could learn from traditional designers.

The four lessons are:
1. Question
2. Care
3. Connect
4. Commit

These are great. I agree a great deal with the article entirely there is a lot of truth to what is being said. I had to laugh for a minute when I read the piece about responses to questions being asked. I used to hear the 22 year bit a great deal when I was in Financial Services space but now I hear more ego or territorial responses in the other industry segments. even though you get those responses it is important to be persistent. I talked a bit about this in my response to the "State of Enterprise Architecture" post.

The care element is not new in principle but is typically stated as "Trusted Advisor" or "Relationship Management". Either way, I like the empathy element of this. It's more than just understand the issues but to empathize with the current pain points, what the customer is not receiving, or the history of events that led up to this point. Enterprise Architects and other roles like them are well equipped for this job. They should be the front line for customer care. Empathy based relationship management should be core.

Connect is critical as well. If you delver a product that is unusable or is not as desired your customer will not use or will not get the right level of adoption you are looking for. As Enterprise Architects we need to sniff these issues out. If a product isn't usable it shouldn't of been built at all.

Very simply, commit equals credibility. This is all about agile delivery of frequent deliveries for rapid feedback. This is where Agile processes like Scrum fit well. If you can not deliver you will not be trusted, you will not have a seat at the table to ask the right questions, to be empathetic, or deliver on a well aligned and useful product. This makes it real.

Here is a portion of the article:

Question. If you spend any time around designers, you quickly discover this about them: They ask, and raise, a lot of questions. Often this is the starting point in the design process, and it can have a profound influence on everything that follows. Many of the designers I studied, from Bruce Mau to Richard Saul Wurman to Paula Scher, talked about the importance of asking "stupid questions"--the ones that challenge the existing realities and assumptions in a given industry or sector. The persistent tendency of designers to do this is captured in the joke designers tell about themselves. How many designers does it take to change a light bulb? Answer: Does it have to be a light bulb?

In a business setting, asking basic "why" questions can make the questioner seem naïve while putting others on the defensive (as in, "What do you mean 'Why are we doing it this way?' We've been doing it this way for 22 years!"). But by encouraging people to step back and reconsider old problems or entrenched practices, the designer can begin to re-frame the challenge at hand — which can then steer thinking in new directions. For business in today's volatile marketplace, the ability to question and rethink basic fundamentals — What business are we really in? What do today's consumers actually need or expect from us? — has never been more important.

Care. It's easy for companies to say they care about customer needs. But to really empathize, you have to be willing to do what many of the best designers do: step out of the corporate bubble and actually immerse yourself in the daily lives of people you're trying to serve. What impressed me about design researchers such as Jane Fulton Suri of IDEO was the dedication to really observing and paying close attention to people — because this is usually the best way to ferret out their deep, unarticulated needs. Focus groups and questionnaires don't cut it; designers know that you must care enough to actually be present in people's lives.

Connect. Designers, I discovered, have a knack for synthesizing--for taking existing elements or ideas and mashing them together in fresh new ways. This can be a valuable shortcut to innovation because it means you don't necessarily have to invent from scratch. By coming up with "smart recombinations" (to use a term coined by the designer John Thackara), Apple has produced some of its most successful hybrid products; and Nike smartly combining a running shoe with an iPod to produce its groundbreaking Nike Plus line (which enables users to program their runs). It isn't easy to come up with these great combos. Designers know that you must "think laterally" — searching far and wide for ideas and influences — and must also be willing to try connecting ideas that might not seem to go together. This is a way of thinking that can also be embraced by non-designers.

Commit. It's one thing to dream up original ideas. But designers quickly take those ideas beyond the realm of imagination by giving form to them. Whether it's a napkin sketch, a prototype carved from foam rubber, or a digital mock-up, the quick-and-rough models that designers constantly create are a critical component of innovation — because when you give form to an idea, you begin to make it real.

But it's also true that when you commit to an idea early — putting it out into the world while it's still young and imperfect — you increase the possibility of short-term failure. Designers tend to be much more comfortable with this risk than most of us. They know that innovation often involves an iterative process with setbacks along the way — and those small failures are actually useful because they show the designer what works and what needs fixing. The designer's ability to "fail forward" is a particularly valuable quality in times of dynamic change. Today, many companies find themselves operating in a test-and-learn business environment that requires rapid prototyping. Which is just one more reason to pay attention to the people who've been conducting their work this way all along.

Full Article
http://blogs.hbr.org/cs/2010/07/the_four_phases_of_design_thin.html

MEGA annonces TOGAF and Business Architecture Offerings

Over the past few weeks MEGA an enterprise architecture (EA) tools provider, has recently announced  MEGA for the TOGAF framework and Business architecture solutions. I wanted to raise awareness of this update as a news item rather than an endorsement of the product. 

MEGA promises users that they can choose to begin an EA project using MEGA for TOGAF, then move seamlessly to a wider implementation using MEGA Process (BPMN Edition) and MEGA Architecture. It seems as if these announcements are aligning business architecture with the technology/solution architecture centric TOGAF. 

MEGA says they will aid TOGAF practitioners in these ways:

• Ensure EA project success by following the comprehensive Architecture Development Method (ADM).
• Facilitate project communication to all stakeholders with the collaborative development of TOGAF 9 deliverables.
• Customize the implementation of TOGAF and ensure all projects deliverables are aligned.
• Build current and future state transition architectures and compare them.
• Identify, document, and publish technical reference models.

MEGA also communicates the value proposition to business architects as well:

• assess and streamline major investments
• improve customer information management
• consolidate post-merger, post-acquisition business units and product lines
• incorporate outsourced and partner solutions
• conform to compliance and audit requirements

Microsoft’s Certified Architect (MCA) replaced by IASA’s CITA-P Certification

IASA’s CITA-P Certification Named by Microsoft to Replace the Microsoft Certified Architect
Austin, TX, (PRWEB) May 3, 2010 -- In a conference call and email announcement on Wednesday April, 28, Microsoft Learning announced that it would discontinue offering the Infrastructure and Solutions architect certifications, and would fund the migration to the Certified IT Architect Professional (CITA-P) offered by the International Association of Software Architects (IASA).

IASA has created a grandfathering process to allow easy adoption of the CITA-P certification for current Microsoft Certified Architects holding the Solutions or Infrastructure specialization. As MCA’s have already gone through a rigorous interview process similar to the CITA-P Board review, the grandfathering process focuses on mapping skills and experience to the IASA skills taxonomy.

Andy Ruth, the Vice President of Education for IASA, launched the MCA Infrastructure and the MCA Solutions credential in 2004 while with Microsoft Learning. According to Microsoft, the credentials were launched to help establish the IT Architect profession at a time when the IT industry needed thought leadership and architectural taxonomy.

Ruth believes the profession should be self managed by the practitioners in the form of a professional association, as in other industries--medical, legal, etc. “The certification of a profession needs to be run by the profession, not from within a vendor with a specific product or technology. Microsoft releasing the certification to IASA is recognition of that.”

“IASA is not trying to sell a product or specific technology, so individuals and organizations can be confident there are no ulterior motives in their certification and education programs,” said Paul Preiss begin_of_the_skype_highlighting end_of_the_skype_highlighting, CEO of IASA. “IASA’s mission is to support architects on their career path, and ensure they have the skills and knowledge necessary to deliver on the core value proposition of the profession: to make and save their employer money through the use of information technology (IT).”

Darren Day, Microsoft Certification Business Manager, who hosted the call for Microsoft said that IASA has "developed large and supportive communities dedicated to the IT Architect profession.” He continued, “They are technology agnostic, respected in the industry, and offer trusted IT architectural programs and credentials for the breadth architect.”

Read the entire release at: http://www.prweb.com/releases/2010/05/prweb3946754.htm or go towww.iasahome.org to find out more.

Solution Guidance Packager for Visual Studio - Feature Builder Power Tool

Recently a good friend and former co-worker of mine, Michael Lehman released the Feature Builder Power Tool for Visual Studio 2010 Preview for RC on the Visual Studio Gallery.  This is a power tool that is intended to help Technical Leads or Solution Architects (.Net focused) to extensions, code snippets, guidance maps of tasks or steps, models which can be shared within Visual Studio or with others in the Visual Studio Gallery. 

 

 

The tool can create two different kinds of extensions using Feature Builder. 

• Standard Feature Extension -  can contain tools, code, and a simple map - it will run on the Visual Studio Premium and Visual Studio Professional editions (in the final version of this tool). 
• Ultimate Feature Extension - can contain everything a standard Feature Extension can contain, as well as rich modeling and visualization tools that can take advantage of the modeling platform inside the Visual Studio 2010 Ultimate edition (required). These tools can be used to provide a logical view of your target solution, and to visualize your existing code. This is the preferred type of extension to use if you intend to provide architectural guidance or share specific refactoring or pattern knowledge.

 

An introductory video (which includes a "hello world" example) is available on Channel 9: http://channel9.msdn.com/tags/FeatureBuilder .

 

Additional information and support will be available via the Visual Studio 2010 Architectural Discovery & Modeling Tools Forum  

Architecture Journal 22: Taking BI Beyond the Business Analyst

• Foreword
• Data-Warehouse Principles for Supporting Enterprise-Enabled BI Applications
• BI-to-LOB Integration: Closing the Cycle
• Increasing Productivity by Empowering Business Users with Self-Serve BI
• Business Insight = Business Infractructure = Business-Intelligence Platform
• Semantic Enterprise Optimizer and Coexistence of Data Models
• Exploring Patterns and Principles of a New Generation of SOA Solutions
• BI Videos

Microsoft Steps Up Architecture Modeling

Sudhanshu Hate from Infosys posted a good overview article on the new architecture modeling capabilities in Visual Studio Team System - Architecture Edition.

However, even though Microsoft steps-up in the architecture modeling capability it still lacks the repository aspects that bring the most value. As an example, each one of the models is still file based stored in a project structure. This isn't conducive to enabling architecture management across an organization. Everything is built in a hierarchy within a project.

One other gap is alignment to architecture modeling standards such as Archimate. I think there is an opportunity for Microsoft to leverage this already developed standard in the same way as they did with UML. Rather what we see now is Microsoft's own definition of what a logical model is.

This is a great first step getting the modeling pieces and kudos to the VSTS Team Architecture folks but I would encourage my friends back in Redmond to align more with the architecture industry standards and build out the a repository to enable systematic reuse and to make application portfolio management a reality.

See below for his post (http://www.infosysblogs.com/microsoft/2009/11/architecture_rules_enforcement.html):

For all these years if a .Net architect has to model the software system. He or she has to rely on modeling tools like Rational XDE, or Visio Enterprise Architect. Personally I was never impressed with Visio Enterprise architect’s modeling support, and code generation it has to offer. Though Visio has several stencils, templates, symbols available; UML modeling and associated code generation was always bit stiff. Integration with Visual studio to synch up models with code and vice a versa was another challenge.  3^rd party tools like RationalXDE has good support for .NET but one has to pay hefty license fees to use such tools.

Result of this, system modeling used to get constrained into Microsoft Word, Power Points, Visio’s. Keeping Word/Visio based models up to date w.r.to the architecture, design, code changes was always a catching game leading the code, designs and overall system documentation out of synch impacting traceability between these artifacts.

Increasingly this has caused the disharmony between architecture modeling and development teams.

After all these years, finally, Microsoft Visual Studio 2010(VS2010) seem to have helped overcome this obstacle by embracing Unified Modeling Language (UML) and making architecture, design, development, testing seamlessly possible through its Integrated development environment. If not all, VS2010 has support for most of the UML diagramming types like

1.    Use case diagram

2.    Activity diagram

3.    Sequence diagram

4.    Class diagram

5.    Component diagram

With VS2010 beta 2, while there are a few UML diagram types i found missing at this point of time like the ones of State life cycle, object, deployment etc. I was impressed with the inclusion of diagram type called as “Layered diagram”. Through this modeling diagram, one can not only depict various logical layers like Presentation (UI), Business logic, Data Access, Utility and Database but also define the dependencies/coupling between them in terms which layer can call which one. This helps in establishing and adhering the architecture rules set by an architect while architecting the system like Presentation layer components should not directly call the data access layer component and vice a versa.

To validate the architecture in code, one can map various project (UI, Service, Data access) files by dragging and dropping into this layer diagram in respective layers and then validate it by using VS2010 “Validate Architecture” option which tracks down any violations in the code.

So far while most of the architects used to write similar rules as part of MS word architecture document but it was left with the wisdom of developer to adhere or violate it, catching such architecture principle violations were difficult in the million Lines of code developed.

Through Layer diagramming architecture validation support, VS2010 will help in keeping the design and code in synch with the architecture and design principles established during the early stages of life cycle. However this is not all with VS2010 architecture modeling support, I have just scratched the surface of what VS2010 has on offer and intend to cover other aspects in coming blogs.

For all these years if a .Net architect has to model the software system. He or she has to rely on modeling tools like Rational XDE, or Visio Enterprise Architect. Personally I was never impressed with Visio Enterprise architect’s modeling support, and code generation it has to offer. Though Visio has several stencils, templates, symbols available; UML modeling and associated code generation was always bit stiff. Integration with Visual studio to synch up models with code and vice a versa was another challenge.  3^rd party tools like RationalXDE has good support for .NET but one has to pay hefty license fees to use such tools.

Result of this, system modeling used to get constrained into Microsoft Word, Power Points, Visio’s. Keeping Word/Visio based models up to date w.r.to the architecture, design, code changes was always a catching game leading the code, designs and overall system documentation out of synch impacting traceability between these artifacts.

Increasingly this has caused the disharmony between architecture modeling and development teams.

After all these years, finally, Microsoft Visual Studio 2010(VS2010) seem to have helped overcome this obstacle by embracing Unified Modeling Language (UML) and making architecture, design, development, testing seamlessly possible through its Integrated development environment. If not all, VS2010 has support for most of the UML diagramming types like

1.    Use case diagram

2.    Activity diagram

3.    Sequence diagram

4.    Class diagram

5.    Component diagram

With VS2010 beta 2, while there are a few UML diagram types i found missing at this point of time like the ones of State life cycle, object, deployment etc. I was impressed with the inclusion of diagram type called as “Layered diagram”. Through this modeling diagram, one can not only depict various logical layers like Presentation (UI), Business logic, Data Access, Utility and Database but also define the dependencies/coupling between them in terms which layer can call which one. This helps in establishing and adhering the architecture rules set by an architect while architecting the system like Presentation layer components should not directly call the data access layer component and vice a versa.

To validate the architecture in code, one can map various project (UI, Service, Data access) files by dragging and dropping into this layer diagram in respective layers and then validate it by using VS2010 “Validate Architecture” option which tracks down any violations in the code.

So far while most of the architects used to write similar rules as part of MS word architecture document but it was left with the wisdom of developer to adhere or violate it, catching such architecture principle violations were difficult in the million Lines of code developed.

Through Layer diagramming architecture validation support, VS2010 will help in keeping the design and code in synch with the architecture and design principles established during the early stages of life cycle. However this is not all with VS2010 architecture modeling support, I have just scratched the surface of what VS2010 has on offer and intend to cover other aspects in coming blogs.