Software Architecture & the Modeling Services Repository

As I wrote about last time, I’ve been watching a number of PDC Videos to see what Microsoft’s been doing that can make a Big IT guy’s job a little easier. In particular, I recently watched James Baker’s and Shoshanna Budzianowski’s very interesting “SQL Server Modeling Services: Using Metadata to Drive Application Design, Development and Management” presentation. I’ve been watching the technologies that started out life as “Oslo” with great interest, particularly in the areas of structural modeling in ‘M’ and the Repository as the engine for metadata-driven software systems.

I spend a lot of time thinking about architecture, especially as it relates to creating leverage – both at the project and enterprise level. In this relentless pursuit of leverage I, like many Architects, rely on modeling as a means of defining an agile architecture. As you might imagine, any tools, techniques, and/or technologies that can compound the leverage gained through modeling is something that grabs my attention. It is from this perspective that I found the demonstrated capabilities of the Modeling Services Repository compelling. In particular, three really important themes jumped out at me:

• The Modeling Services Repository as a centralized UML repository
• The Modeling Services Repository as a means of bridging architecture, design, and implementation
• The Modeling Services Repository as a means to gaining insight into both of the above

Centralized UML Repository

James’ demonstration of loading a model created in Rational Software Architect (RSA) into the Repository via XMI is very, very significant. As I mentioned briefly in my last post, Modeling Services as “architectural glue” for heterogeneous IT environments is a powerful tool for Big IT Architects to get a handle on their enterprises. The possibilities of centralizing UML models across an enterprise, without enforcing tool standardization, can’t be underestimated (ever tried to get a Data Modeler to give up ERWin? ;-). As is illustrated by the preso, in the era of web services and other standards-based integration, you can have Java architectures relying on .NET services (and vice versa). Having a centralized repository for UML models allows for cross-organization impact analysis as well as facilitating robust architectural reviews (I’m imagining Developers reading this shivering in fear, while CIOs are rejoicing ;-).

Bridging Architecture, Design, and Implementation

As a former Developer and currently practicing Architect, I can personally attest that bridging the concepts of architecture, design, and implementation is not easy (for compelling definitions of each of these, IMHO, look here). In software-intensive solutions, the following scenarios are typical:

• What often passes for architecture is crafted in meetings, but not always written down. When it is written down, Word, PowerPoint, or Visio are the usual suspects.
• Technical (as opposed to Functional) design docs/specs are often the purview of members of the team fulfilling the traditional Systems Analyst role (these days this role is usually played by Architects, Developers, Business Analysts, you name it). In these situations, lots of ambiguous prose is often the unfortunate order of the day.
• The IDE is where the rubber meets the road in terms of implementation. That is, the IDE is where the Developer morphs both architecture and design in real-time to produce what really matters in the end – executing code – based on the Developer’s understanding/interpretation.

Big IT readers will be intimately familiar with the personas and scenarios that relate to the three bullets above.

The Repository offers a compelling vision for addressing the disconnects between architecture, design, and implementation. First, the repository can function as a centralized repository for architectural models (e.g., Krutchen’s excellent 4+1 model) crafted in UML. Second, a central repository can also store rigorous design docs/specs that leverage UML (want better specs? Take a serious look at Literate Modeling for some inspiration) and provide linkages between the architectural models and the design models. Lastly, the Repository allows for traceability from architecture to design to implementation through the ability to query across the Repository’s UML2 and System_Runtime models.

A colleague of mine on the MSIT Enterprise Architecture team and I discussed the tremendous value of such a capability just yesterday. I’m confident that seasoned Big IT Architects would heartily agree.

Gaining Architectural Insight

The no brainer scenario for the Repository is taking advantage of the bridging of architecture, design, and implementation to gain architectural insight. This insight takes many forms, but here’s a quick brainstorm (I won’t reiterate all the scenarios that James and Shoshanna enumerated in their preso) that would make my life easier as an Architect:

• Providing automation to accelerate the execution and quality of Design Reviews
• Providing automation to accelerate the execution and quality of Architectural Reviews
• Providing automation to accelerate the execution and quality of Deployment (think UML Deployment Diagrams in the Repository – sweet!)

I would argue that a corollary to providing cross-platform bridging of architecture and design (i.e., XMI import from UML tools), is providing cross-platform bridging of implementation. As a career IT guy I love the capabilities offered to me via the System_Runtime metamodel. I just would argue strenuously for adding such capabilities for other platforms as well. The goodness of a heterogeneous IT shop being able to import Java/J2EE implementation metadata into the Repository along side .NET implementation metadata is very exciting for an IT weenie like me. Hopefully we will see capabilities just like this added SQL Server Modeling Services over time.

Any thoughts from the IT community would be greatly appreciated. Am I in the ballpark with this line of thinking?