Inside Architecture

Notes on Enterprise Architecture, Business Alignment, Interesting Trends, and anything else that interests me this week...

April, 2009

Posts
  • Inside Architecture

    Rubik’s Enterprise Architecture

    • 4 Comments

    In many ways, the task of creating a complete roadmap for the evolution of an enterprise architecture is similar to the task of creating an optimum path to solving rubik’s cube.  With rubik’s cube, the number of total possible combinations of faces is very large.  (There are 43,252,003,274,489,856,000 different cube positions).

    Yet, a number of years ago, Herbert Kociemba published an algorithm that would not only solve Rubik’s cube, it would do it very quickly.  (You can download an easy-to-use application that provides you with a solution from his web site.)  His most recent version of his app would solve 7,000 cubes per hour!

    So, if it is possible to create a pathway from nearly any combination of Rubik’s cube to a “clean” solution, in 21 moves or less, and to calculate the “roadmap” in less than a second, why is it so difficult to describe the optimum pathway from a “present state” enterprise architecture to a “future state” enterprise architecture?

    The advantage that Kociemba had was that the “clean” or “solved” state was fairly easy to describe.  All sides have the same color.  The “clean” state of an enterprise architecture depends on a lot of things, and there may not be one answer.  There can be many “right” answers, each describing a unique configuration of systems, data flows, events, interfaces, technologies, and business process activities. 

    Another advantage that he had: the solution path did not have to be suitable at any particular step of the way.  In other words, you could create any configuration of the cube, at any step, as long as the final configuration was that of a solved cube.  Not so with an Enterprise Architecture.  At each step of the way, we have to have an environment that is functional and, in most cases, just as capable as it was before the last set of moves was made.

    Even with all these constraints, the mathematical feat of solving Rubik’s cube in an optimum number of steps has been accomplished.  I don’t believe that it would be more difficult to solve for the “optimum” enterprise architecture.  A different problem, true, but one of similar complexity.

    Now, there have been “tried and true” methods for solving the cube for years.  I learned one when I was a teenager.  Regardless of how the cube started, you could follow the set of patterns and, in about 150 moves, you could solve any cube.  Kociemba provided us with an optimal path that was NOT a “mathematical reduction” of the tried and true methods. 

    And perhaps that is the more interesting result of making this comparison.  We should not expect that the optimum architectural roadmap is a simple reduction of the “tried and true” architectural roadmap.  In other words, for any environment, if you describe all the moving parts, the steps needed to get you to a simpler, less expensive environment may not be obvious.  More importantly, you cannot describe a “long path” and then simply “shorten” it by substituting simple sequences of moves with shorter sequences.  There may not be a short cut to the optimum solution.

    So the next time I hear an architect or a product salesman tell me that they have the “perfect” solution to my problem, I’m going to think about Rubik’s cube, and Kociemba.  The “optimum” solution may not be the obvious one.

  • Inside Architecture

    Why Agile Development Requires Agile Architecture

    • 14 Comments

    The dark cloud of the economic downturn has produced a silver lining within Microsoft IT: an increased emphasis on Agile development techniques.  This does not mean that MS IT is new to using Agile.  Far from it.  Agile development practices have been used in various IT groups here for nearly a decade. 

    What is new is the desire to address the basic development and governance processes themselves to remove the “Bias towards Waterfall” that exists in many of them.  That bias can create a situation where someone can choose to be Agile or choose to comply with corporate policy.  That’s a devil’s choice. 

    For example, we have a governance point that is used throughout all levels of the IT organization called “Baseline” where all design and specification (and estimation) is done, and signed off.  This is supposed to occur before software is delivered.  Does that favor waterfall?  You betcha.  This governance point is mentioned in one of the metrics all the way up to the CIO scorecard!  BDUF is built in to the DNA itself.

    But if you look at the reasons that people give for requesting BDUF (Big Design Up Front), it goes like this: you can reduce risks by requiring that everyone understands and agrees with the requirements, features, scope, timelines, responsibilities, deployment model, etc…

    Right.  Pigs fly.

    I do see the intent, and it is honorable.  Reducing risk is a good thing and we want to increase the number of systems that are delivered on time and on budget with fewer defects.  But I think that Agile methods have proven that there is another way to accomplish the goal of “improved delivery.” Unfortunately, they do not fit into the same neat little box. 

    Where waterfall requires 600 pages of documentation to be written up front, Agile requires that most of those pages are never written.  It is not correct that Agile methods produce design documents “as you go.”  That is nonsense.  Agile methods produce 10 pages of diagrams, and nearly no accompanying text. 

    So is architecture a BDUF process? 

    Some of it is.  If you follow the RM-ODP model or 4+1 views, you are going to be tempted to over-specify and over-architect.  After all, the 4+1 views present a mechanism for creating a “complete” model of a software system.  That’s great, if you want to create a complete model of a software system.  But why would you want one?  Why would it be a goal to have a complete description of a software system outside the software itself?  Would a “partial” description serve the needs more effectively?

    BDUF architecture is rarely a good thing.

    Agile architecture, however, is often a good thing.  Agile architecture is the act of producing enough architecture to meet the needs of the project, and nothing more, and producing it in a timely fashion, with a minimum of effort.  Agile architecture RARELY produces a detailed class model in advance. 

    Agile architecture often produces a high-level component model and context model to establish the existence of components, their names, and perhaps even the division of responsibilities in the dev team itself.  (think: Scrum of Scrums).  Agile Architecture nearly never produces diagrams of technical things, like the structure of a message.  Dev tools do that, from the code itself.

    Agile architects will produce models using a dev environment tool, like Visual Studio or Sparx Enterprise Architect, not a diagramming tool like Visio that cannot easily be connected with the code. 

    Agile architects will use diagrams to communicate between people and to express artifacts into code where developers have real freedom to make the magic happen.

    Agile architects will not only leverage patterns, but also complete reference models.  They will consume a well-built reference model, inject the components that will be developed for the application, and get the team off on the right start.  They will not “craft a new architecture” for every need, but will build-from-pre-existing-designs 80-90% of the time using frameworks that produce maintainable, secure, reliable, and easily deployed systems.

    Failure to architect a system is a failure to deliver.  On the other hand, hand-crafting every system is also a failure to deliver.  The difference between the two, and the middle-way that defines success, is agile architecture.

  • Inside Architecture

    Towards an Enterprise Business Motivation Model

    • 6 Comments

    Today marks the end of a long dry spell.  As of today, I’m back in print with an article in the Architecture Journal called “Towards an Enterprise Business Motivation Model.”

    AJ19_EBMM_Callout

    Of interest to Business Architects, Strategists, Business Planners, and Management Consultants, the Enterprise Business Motivation Model (EBMM) is the first published model to consider the needs of the multi-faceted modern business, one where the needs of many divisions, and many business models, have to be considered.   

    Finally, a model where the competing strategies of many business units can be captured, displayed, compared, prioritized, and placed on enterprise-wide roadmaps. 

    I made some controversial decisions in putting this one together.  I don’t expect that everyone will agree with the choices I made. 

    Update from the author

    Since publishing the article on MSDN, I have continued to maintain the actual metamodel for the EBMM on it's own website (http://motivationmodel.com).  If you would like to know more about the EBMM, please visit that site to discover the core elements of the model, and the methods that I used to create it.  You can download a PDF of the model or a model file from Sparx Enterprise Architect that will allow you to navigate it easily.  Also on the EBMM site is a complete html sub-site created by the Sparx tool allowing you to navigate through the model, visit connections, and examine the definitions for each of the terms.

  • Inside Architecture

    Reducing IT overhead by managing the list of IT standards

    • 2 Comments

    In tough economic times, we tend to look for ways to cut costs and reduce overhead, so that we can “do more with less.”  In our team, we’ve stumbled upon one such way that I’d like to share.

    One of the responsibilities that tend to fall to Enterprise Architecture, in many organizations, is to be the “keeper of the standards.”  As many readers of my blog know, Microsoft IT was reorganized a couple of years ago to merge the management of 13 different IT units into one cohesive organization.  We are still working through that process, with one result being the recent addition of the “keeper of the standards” role to the EA team.

    Previously, EA could create standards, as could other teams.  The project teams themselves would follow what they could.  Some were consistently enforced (like privacy and security). Others were hit-and-miss.  A developer in one IT division may have substantially different standards from a developer in another division.  

    Not long ago, our CIO sent our EA team out on a rather unique discovery mission: catalog all the standards that exist in any part of IT, and bring them under one framework so that we can reduce the overlap between various standards and create a consistent and defensible set that most everyone can follow.  It turned out to be tougher than it sounds.

    Across various IT units, we flushed out thousands of documents that purported to espouse one standard or another. 

    And here is where the cost savings opportunity appears.  The processes surrounding the application of IT standards were all over the map.  Some teams performed consistent code reviews, but only reviewed a few standards.  Others had a long laundry list, but many of their developers were not even aware of them.  Many departments wrote standards that they wanted other departments to follow, often with complicated results.  It was a real mess.

    To address the problem, we’ve created a framework for simplifying these standards and a v-team to make decisions.  The CIO is driving IT managers to reduce overlap, clarify the objective of each standard, and prioritize on the ones that deliver the most value. 

    Once this is process is complete, I expect we will have a much simpler and more consistent view of the standards that various IT stakeholders will need to follow.  In addition, we will have a simplified process for getting standards approved and visible, allowing the truly beneficial standards to take hold more quickly.

    In later blogs, I’ll discuss the costs, and benefits, of standards.  For now, I wanted to share this business opportunity with architects in other EA groups.  Manage your standards, and you can cut costs and raise quality in a consistent manner.

  • Inside Architecture

    Will there be a battle between Archimate and the UML?

    • 11 Comments

    A friend was kind enough to remind me, this morning, that Archimate is still kicking around and making noises.  In fact, for a modeling language that’s been in quiet development for many years, Archimate having something of a rebirth as it is now part of the Open Group.

    Many Enterprise and Solution Architects are already quite familiar with the Open Group.  This is the standards body that originally formed around Unix standards and has since taken on a variety of different domains including the popular architectural process model and framework: TOGAF, which just released version 9.

    Unlike TOGAF, many folks are not so familiar with Archimate.  This approach to modeling enterprise architecture was developed in the Netherlands by a public-private partnership of the Dutch government, industry and academia.  The IP for Archimate was handed over to the Open Group in 2008 and was blessed by that group as a standard last fall.  (If the Open Group were actually a group that represents EA, the blessing would have carried a little more weight, but that’s life.)

    Alas, there were many sophisticated metamodels in existence before Archimate.  Each of the major vendors of EA tools uses a metamodel.  I cannot say that I’m familiar with all of them, but I am familiar with a few, as well as the metamodel that we’ve developed internally inside Microsoft IT.

    Unlike the UML, Archimate didn’t start with a variety of different problems to solve, each with their own language.  UML (+BPMN) is a collection of models that has come together over time from sources in academia and industry.  What UML lacks is a solid and consistent metamodel that defines how the parts of different models are expected to relate to one another.  In other words, UML does not answer the question: how does a business process relate to an IT service.  Archimate does.

    Archimate started with an understanding that these problems relate to one another;  that the entire complex and difficult business of understanding IT requires a rich inter-relationship of completely different domains, from business motivation to business process to managed services to systems to infrastructure.  Thus Archimate goes where UML doesn’t: it defines a metamodel that allows these relationships to be constructed, and constrained, and communicated.  The constraints allow analysis, traceability, governance, and consistency.  UML is unconstrained between model types.  Archimate is not.

    That is its strength. 

    It’s weakness is in the visualizations themselves.  For some reason, the Archimate foundation felt the need to redefine the visual language of architecture, reusing familiar images from UML while redefining their semantics.  This approach was used instead of leveraging and extending the UML notations.  I cannot say that I agree with the approach.  I find it unfortunate, with the consequences for confusion and a slow adoption process across industry.  

    As for the metamodel: Archimate has one, or at least, part of one.  That puts it in good light with me.  That doesn’t mean I believe that the Archimate metamodel is correct. 

    I’m not saying that Archimate is right or wrong.  I have not reviewed it in detail. (I cannot.  The open group ‘published’ the ‘standard’ to their members only, not to the rest of the world.  Is that what they mean by ‘open standard?’ hmmm.)  [update: since writing this post, a reader has responded with links to an online resource which provides details of the archimate notation and metamodel.  See the comments for those links.  They were NOT made available by the Open Group.]

    Is it Archimate vs. UML then?  Maybe.  The diagramming model that is included in Archimate clearly overlaps with UML.  On the other hand, they solve different problems.  Archimate is a mechanism for understanding the meta-architecture of a technology environment.  UML fits nicely under the covers, describing the implementation of the systems (both technical and process systems) from various viewpoints. 

    In effect, Archimate describes the structure of cities, while UML describes the structure of houses and office buildings.  Both are needed, and they solve different problems.  In that way, they do not intersect at all.  Unfortunately, the diagramming notations are not so consistent.

    If the Open Group were to create an accord with the OMG whereby OMG would own UML intra-model semantics while the Open Group would own UML inter-model semantics, then the Open Group could simply use the UML diagramming notations in the Archimate specification.  I don’t know if something like that is possible, but we’d all benefit.  If not, then I’d like to see Archimate use completely different visual representations than the UML, so that there is never any confusion.

    Either way, the metamodel, or part of it that Archimate represents, has started to emerge in standards.  This is a healthy thing.

  • Inside Architecture

    All the questions fit to answer

    • 4 Comments

    As we look to using tools for Strategic Planning in IT, I am constantly reminded of the fact that many business people don’t know what Strategic planning is, or why anyone should bother doing it.  This is not a Microsoft thing.  As I read the reports from our consultants in the field, and speak with tool vendors and consultants in the EA space, one bit of advice appears over and over:

    Make sure you write down the questions that the business wants the Enterprise Architecture team to answer.  Then collect only the information that you need to collect in order to answer them.

    Two things hit me when I consider this advice:

    1. The advice is excellent.  EA can get sidetracked by Ivory Tower problems, answering questions that no one is asking.
       
    2. Wow, we have an immature industry.  Perhaps I’m mistaken, but don’t mature practitioners of any repeatable process have a set of questions that they need to get answered?  

    I’d like to see a time, in the not-too-distant future, when we can offer a course in graduate school on Enterprise Strategic Planning in IT, and one of the final exam questions would read: “List all eight of the key questions that are answered through strategic planning?”

    I’m planning for the day when the questions will be standard, the answers easily gained, and the value of asking the questions will be so obvious that an EA team can be held accountable if they fail to ask, and answer, them.

     [[added by Nick: 18 May]]: as a response to another post, I was presented with a link to a site, operated by a set of researchers in Germany, where the site owners are attempting to catalog 'patterns' of concerns and bits of information models useful for answering those concerns.  This is the first really comprehensive attempt I've seen to address this issue, and I applaud it.  For those interested in Enterprise Architecture, I strongly suggest that you keep an eye on these folks: http://eampc-wiki.systemcartography.info/wikis/eam-pattern-catalog/home

Page 1 of 1 (6 items)