Wednesday, May 26, 2010 |

The Open Group committee made a conscious choice to encourage customization of TOGAF, since every organizational context is unique. After all, TOGAF is a framework, not something you swallow whole to get well.  If you look at the first BPMN sub-process below, “Select Reference Models, Viewpoints, and Tools” from Part II - ADM Phase B: Business Architecture, you can see that customization is built right into the process steps themselves.  

(See the text in TOGAF-->Part II - ADM-->Phase B: Business Architecture-->Steps.)
The above diagram is not unreasonable but notice there are no roles defined for any of the tasks or sub-processes. You’re supposed to define the roles yourself earlier in Phase A: Architecture Vision.

Also consider these additional customizations in TOGAF:
  • You’ll need to connect viewpoints, although they’re catalogued in another section, to specific stakeholders. And maybe the viewpoints listed aren’t for you. TOGAF says that it is not a complete list and that you’ll need to customize these for your purposes.
  • You’ll need to define artifacts required by you and your stakeholders for each phase. Again artifacts are catalogued by phase but you’ll need to accept or reject them for your purposes. In SenseAgility’s TIMM we’ve invented new ones and new uses for existing diagram types.
  • Diagrams and artifacts have text explanations but no sample views, even the ones that might be graphical. You’ll have to experiment with these approaches.
  • Deliverable samples are nearly non-existent although Stakeholder Management and Business Scenarios and a few others are fairly covered.
So if you’re feeling some disconnectedness with the TOGAF approach you might need to realize that some work is required to fill in your customized version of TOGAF.  Our customized version of TOGAF is TIMM and our Capability Based Business Architecture seminar covers TOGAF Phase B: Business Architecture.

EA's Big Missing

Tuesday, May 18, 2010 |

Enterprise Architecture (EA) organizations across the country have been hammered. As if the severe recession wasn’t enough, there are other reasons to account for this. Here are a few:

  1. EA organizations are notoriously unable to prove value.
  2. EA frameworks do not yet help EA organizations to prove value.
  3. EA tool vendors generally don’t help EA organizations to prove value.

Unfortunately the climate in the EA community is still inwardly focused on IT issues and not outwardly towards client concerns. That’s another reason EA doesn’t receive funding.

As we've seen lately in our review of TROUX, value for capabilities is missing but costs aren't. How can you show value in such a situation? And that’s not rhetorical. With or without a tool, if your EA organization itemizes costs without linking them to value provided, then the only thing they can show is that EA activities are a drain on the corporate treasury. That's not to say that there is no value to EA - and probably not what the EA team wants to communicate.

EA’s and EA leaders need to focus on a cost benefit analysis (CBA) of their capabilities. A CBA is part of your critical path - all the more so if your CIO reports to the CFO.

All is not lost if you haven’t come to this conclusion already. But start now to improve your EA image on a value basis.

Buzzword Central

Monday, May 17, 2010 |

I'm looking into AgilePoint BPM Suite for a client. I haven't heard much about this particular tool good or bad, but since this client is not small - nor are they interested in getting smaller - I want to make sure that whatever "plumbing" they decide on can support their current and future scale.

When I ran across this graphic on the vendor site, I was overwhelmed by the sheer number of buzzwords on the picture without any semblance of what it all meant, except to say that it's metadata driven. Really?! Is there a non-metadata driven BPMS?! Are you kidding me?! A list of questions suddenly arose. Where is rules management? How about BPMN support? Or XPDL? Or BPEL? If folks at AgilePoint are interested, I'll be glad to help them build a professional diagram for their site.

EA Tools Matter - Just Not That Much!

Saturday, May 15, 2010 |

After spending some time critiquing new release from Troux Technologies, I received a lot of inquiries about other tools. Since SenseAgility has a vibrant Enterprise Architecture practice, I've dealt with a lot of these tools either through evaluation or implementation - perhaps even all of the ones listed in Gartner MQ and Forrester Wave. But we're not Gartner or Forrester - so the critique was from the point of whether the new improvements in Troux make our life easier - (and you can read below that they don't, and least not yet.)

Here are some of the queries I've received:

"What do you think about IBM's System Architect?"
"Why don't you like Alfabet's PlanningIT EA Tool? Is there something better?"

The answer is simple - every single one of these tools work. Whether they will be successful in your environment is another question, and one that analysts won't be able to answer during your 30 minute call. And the single greatest determinant of success is not whether it's IBM, or Alfabet, or Troux, or any other vendor.  They all have their strengths and weaknesses, and they all have their own meta-models. They all have widgets, whether Flex or .NET based, and they all have standard reports to delight most technical architects.

Those are important, but not as important as whether your EA group has an Architecture Blueprint Method that's been agreed upon by all of their stakeholders - a way to consistently model overall system architecture at all levels of OSI stack, from network through application.  If your EA group has one, then it is more likely that EA tool implementation will yield a positive ROI (project success can never be taken for granted.)  If your organization does not have an ABM in place, don't worry about which tool to purchase. Investing in any of them will likely result in a waste of time and treasure.


Troux Technologies introduces TOGAF 9 ADM Support

Thursday, May 13, 2010 |

No, this is not a free promo for Troux.  I did have an opportunity to listen in on the release conference call/presentation and this is my impression.

The Good:
  • Full TOGAF 9 ADM 
    • This is important for any Enterprise Architecture (EA) group that will be leveraging some portions of TOGAF.  Let's face it, nobody should even attempt to use all of TOGAF, but at least the capability to do so is in the product.
  • Flex-based widgets 
    • Yes, I like them despite Steve Jobs' personal crusade against Flash.  Proposals are proposals, but give me something that works now.
  • Support for Capabilities
    • Obviously, I'm all over this since there are no tools on the market that explicitly support our primary analysis techniques.  This is an important step in the right direction, though as I'll explain below, it's only step 1 of many more.
  • Modernization Roadmap Options View
    • I single this widget out because of its potential impact.  Anyone who's had the privilege of creating PowerPoint presentations with roadmap options will find this feature extremely useful.
  • Collectors for CMDB information 
    • Alleviates that master data management headache.
The Bad:
  • Custom notation
    • I know the icons look a lot nicer than standard Archimate set.  But to anyone who doesn't know the tool, this is a barrier to productivity.  So wouldn't it be nice if it were the standard Archimate set?  Especially since Archimate is also owned by the Open Group.
  • Out of the Box Spaghetti 
    • Standard views of the architecture are simply scary.  This tool seems to have been created with a single stakeholder viewpoint in mind - that of the technical architect.  This, however, restricts a lot of its generated graphics from being utilized as presentation material out of the box.
  • Capabilities are NOT about Cost!
    • Since this is our primary analysis technique, a lot of comments here.  
    • It appears that Troux product team has read what Forrester, Gartner, and SenseAgility have been saying about capability-based analysis, but  didn't quite understand why they are valuable - in a word, value.  Capabilities in Troux are all about cost management, when in reality, they are about value management.  If a CIO comes to the table with a list of costs of capabilities without pairing them to value delivery (e.g. KPIs), they shouldn't complain that they are being managed as a cost center.
    • There didn't seem to be an intuitive way to create capability dependencies.  It looked like the product team took available presentations of capability swim lanes (mine among them) without realizing that  dependency lines are usually removed for presentation purposes.  Oh well.
    • Still waiting on response on how to create capability portfolios, if that is at all possible.
The Ugly:
  • There are 3 main issues that Troux product team should consider for future releases:
    1. Capability-based analyses tools seem incomplete, which makes it worse than not being there.
    2. Troux Accelerator packs were mentioned, but without a localized Architecture Blueprint Method, populating and keeping the Troux Metaverse in synch with reality on a timely basis is difficult.
    3. It's nice to see CMDB integration, but what about Process repositories?  Rules?  GL?  It'd be nice to see more focus on master data management when applied to knowledge repositories.

Good next step that keeps Troux ahead of competition, but still far from a full EA platform.

Why Cloud-Sourcing is Here

Tuesday, May 11, 2010 |

Consider two projects with similar business and technical capabilities delivered:

  1. Online analytics and business intelligence portal built with standard BI development and off-shoring practices.  From initiation to end, 9 months and $1.4mm, on time, and +/-5% of budget - a successful project.
  2. Online analytics and business intelligence portal built with cloud-based BI provider, using "expensive" on-shore development team.  Same methodology, 3 months and $500k - quite a bit ahead of schedule and budget.

I'm a skeptic by nature, so I tend to wait out the hype.  And when it comes to Information Technology, the amount of hype generated can only be bested by the entertainment industry.  Early last year, I took a wait and see approach for "cloud" since it was generating a lot of hype.  But then, these two projects occurred back to back.  Once you get past the hype, there are significant cost savings and time to market gains that cannot be denied.  In a sense, cloud-sourcing showed me the money, and fast.

That's not to say that all is wonderful in going to the Cloud.  Several of respondents that I interviewed for the "Diagnosis:  Cloud-Aware Applications as Competitive Advantage" presentation were very blunt about challenges of migrating existing applications and existing application development methods into this brave new world.   Both methodologies and design principles have to be tailored (and then followed and measured rigorously) to allow for an effective cloud-aware application.  However, with cost effectiveness and time to market opportunities inherent in creating effective cloud-aware applications, it is certainly an investment worth making.


Of Metrics Programs and Governance Capabilities

Friday, May 7, 2010 |

Over on TWDI, Wayne Eckerson has a very thought provoking post on "12 Characteristics of Effective Metrics."  And while all 12 are important, the one that caught my eye as fraught with the more difficult challenges is 'game proofing'.  Here is Wayne's definition:

Organizations need to test all performance metrics to ensure that workers can’t circumvent them out of laziness or greed or go through the motions to make a red light turn green without making substantive changes. “Users always look for loopholes in your metrics,” says one BI manager. To prevent users from “fudging” customer satisfaction numbers, one company hires a market research firm to audit customer surveys.
Seven deadly sins indeed, or as OMG calls it, the Business Motivation Model.  Understanding capabilities being measured gives the Metrics and Measurement groups (e.g. IT Effectiveness, Office of CIO, Office of CFO, etc.) ability to create a program with governance capabilities built in to insure against such gaming.  Importance of using capability-based approach here cannot be understated - if organizations can't trust their metrics to reflect reality, the value of their Governance, Risk and Compliance (GRC) investments will be severely diminished.