Day 3 sessions included:

• Philippe Desfray’s discussion on Modeling TOGAF Enterprise Architecture using OMG
  

  escallope!

  Standard.  Philippe provided insight as to how TOGAF does not enforce the usage of any other standard or practice.
• Shankar Babu Chebrolu provided perspective on Cloud Collaboration in the supply chain.  Cloud adoption best use cases were discussed as well as the serious challenges that still exist in this space.
• Dave Hornford’s presentation Recalculating: Scenarios & Revision for a Live Roadmap touched on how not to confuse a road map with a project plan.

• Dr. Saeed Al Dhaheri presented IT Capacity Build Up and Enterprise Architecture Enablement at the UAE Ministry of Foreign Affairs.  Al Dhaheri shared how enterprise architecture enabled the UAE MOFA to reduce both costs and schedule time by 17%.
• Peter Haviland’s talk on World Class EA 2012 highlighted the importance of change management in transformation.
• Daniel Spar kicked off the Business and Innovation track with an interactive  workshop on framing and constructing architectural artifacts to enable business innovation.

Lunch was enjoyed overlooking the Mediterranean while the team reviewed the afternoon session schedule, which included:

• Suresh Done presenting Agile Enterprise Architecture Methodology with insight into balancing developing a Baseline Architecture vs. the Radical approach

We have also been actively tweeting throughout the sessions – check the @systemsflow stream from us and other conference participants!

Mark your calendars – tomorrow (Day 3), Jim Hosey presents as part of the “Architecture Methods and Techniques” track. Jim will be delivering our approaches to assessing architectural significance of projects, including different tools and techniques we use successfully in our IT architecture work every day.

Highlights of Monday’s morning sessions included:

• The traditional warm welcome from Allen Brown, Open Group President & CEO (with whom we chatted informally during dinner Sunday evening at the brasserie).
• Business Models, IT and Enterprise Transformation presented by Alex Osterwalder.
• EA and Transformation: An Enterprise Issue, A New Role for the CIO? – complete with an interesting and complex case study – presented by Eric Boulay and Hervé Gouezel.
• Why We Can’t Agree on What We Mean by EA presented by the always thoughtful Leonard Fehskens.
• Jes McPhee spoke of the Role of EA in Enterprise Transformations.

We discussed the sessions over a beautiful lunch from the rooftop Panorama of the JW Marriott. The team enjoyed spectacular views of the Mediterranean and mingled with fellow attendees.

Espresso, Riviera style!

After lunch we sat in on:

• Are We Ready for Cloud Semantic Interoperability? presented by ZapThink’s Jason Bloomberg. (Hint: We’re not.)
• Business Process Centered Business Transformation presented by Microsoft’s Krishanaswamy Srinivasan

Some takeaways from Monday’s sessions:

• Messrs. Boulay and Gouezel proposed that a longtime primary IT goal of reducing IT budget is “an old question to ask.” The new question is: “What is my value?” Delivering value is the key to gaining trust and, by extension, gaining a seat at the table to discuss strategy and transformation. Alternatively… if, for example, you deliver a time-sensitive project late but under budget, you’ve failed to deliver value. And failing to deliver value erodes trust and future opportunities.
• Jes McPhee echoed a similar sentiment when he said that showing value early “buys you the right” to work on “the next piece.”
• Len Fehskens put forth a thought-provoking analysis of why enterprise architects still can’t agree on what EA actually is. There is much more to the presentation, but this point stood out: In the process of delivering, architects take on (or are asked to perform) many additional tasks that are beneficial to the project. Often these tasks are only very loosely related to architecture. The value of an enterprise architect thus becomes diluted, and the EA role itself becomes considerably broader and more complex than it should be.

We’re heading to the networking reception now… stay tuned this week for more updates!

P.S. Keep an eye on @systemsflow and @theopengroup for tweets!

• Scope is clear and agreed upon,
• Requirements are carefully crafted,
• Required project roles are present (aka. the Venn of Success),
• Schedule allows freedom to discuss, plan, and execute proven patterns of architecture,
• Timelines are realistic: thoughtfully vetted and agreed upon, and
• Everyone is looking forward to the beautifully crafted UML models

…. cue the music!

Have you ever really been there?   Don’t worry, you already have the tools needed to succeed!

Simplify your approach and use these strategies for an effective, productive, and satisfying outcome.

1. Drive solutions: Propose to the project manager, technical project manager, or business analyst – or whoever is lacking direction specific deliverable – that you can help with some  goal oriented diagrams.  Get diagramming and show some quick results!
2. Demonstrate efficiency: Easy stuff – be on time, be prepared, and have clear agendas for your meetings.  Run your meetings to be organized and on topic.  Distribute home-run meeting recaps.
3. Migrate to success:  There will always be people who “get it” and those who by nature will resist.  Work with the former, show them what you are doing and why – you will end up with new allies in the room.  Eventually, your successes will win over the rest.
4. Expand your architecture offerings: if the task is not in your job description but is in your tool belt,  offer to help – and over-deliver.  You will end up with increased visibility which will lead to requests for the work you want to do.

One architect can make a difference!  Don’t forget to guarantee your own success by setting expectations with a Term of Reference document.

And be careful out there.

The Open Group introduces this conference as a forum to “… gain the tools and knowledge you need to introduce meaningful Enterprise Transformation:”

“Enterprise Transformation is increasingly bringing the IT organization together with the operations and functional parts of the enterprise to make real and sustainable change. At this conference we will hear how it is being addressed by the people involved in these activities and from industry leading experts; providing ample opportunities for networking and discussing the challenges and opportunities with the speakers and other attendees“

Jim Hosey will be presenting on the topic of  Assessing Architectural Significance:

“Knowing when and where to engage an architect is a critical factor in successfully managing an IT portfolio, particularly in organizations where architects are scarce — and often expensive — resources. Many times it is clear which projects would benefit from the participation of an architect; in other cases, the decision is not so obvious. In these not-so-obvious cases, a structured means of assessing a project’s architectural significance is key.

This instructional session presents a lightweight, flexible set of techniques and guidelines for assessing the architectural significance of a project to aid in determining when to engage an architect. Using real-world examples, we will demonstrate these techniques and their application, and will explore how they can be tailored to fit IT organizations of different sizes and with various portfolio mixes.”

We hope to see you in Cannes!  If not, be sure to follow our twitter musings as the conference unfolds.

Beyond the basic methodology, I do have some specific pointers that help me, many of which I have extracted from the many task schemes that have not worked out for me (many of the ideas come from David Allen’s Getting Things Done approach). Anyway, here is my regurgitating of the key things that work for me:

• Don’t keep tasks in your head. That just creates stress. Write it down and free your brain to think impressive thoughts, create amazing deliverables, and guide complex stakeholders.
• Not everything needs to be tracked as a task. Yes, I know. That contradicts what I just said. However, the more noise you put on your task list, the more the important ones get lost. Some things will happen without you needing to track them. For a contrived example: if you have a task to make 50 copies of a document, you don’t need to also have a task to print the document – that will “happen” when you go to make the copies and realize you need the original. Sounds obvious, but I find myself having to police my task list for these, which is why I mention it.
• Only track near term tasks to detail. Still part of the “less is better” theory. A lot can change in a week, at the very least priorities are adjusted, at the most complete direction shifts can occur, so over-tracking the details of next weeks tasks is just creating additional work. Also, future milestones belong on the calendar, remember!
• Use a list of projects to help brainstorm tasks. In addition to my calendar, I use a list of current projects I am currently working and ask myself for each,”Is there anything I need to do in the next few days to move this project forward?”

Remember to review your tasks daily.  Otherwise you are just goofing around.

Once you get your tasks in order and have some free time, two additional sites that I have extracted some organizational gems from are 43 Folders and Lifehacker.

My colleagues and I opine frequently on the ever elusive goal of seamless task management. Our individual roads to chaos are littered with task management schemes and tools: each proposing to do what the others have not been able to do – to tame the insanity and optimize efficiency. In the end, what I have found most effective is almost the first organization approach I ever employed and one I implemented in a completely analog manner.

For nearly ten years beginning when I was in college, I ran a overnight summer camp. At the time, it was an organizational challenge for me – 100 staff, 12 groups, 300 campers, and roughly 420 weekly activities for 12 weeks. Add to that the expected number of hourly crisis and it was a handful. It took a few years to get my organizational stride, but in the end what really did the trick was 4 pieces of paper and a pencil.

Page 1 was simple list of tasks for the current day or the next few days following.

• The list started the day in priority order.
• Items would be crossed out as they were completed.
• New tasks would get added to the bottom as they popped up.
• Important tasks would be annotated with an appropriate number of stars.
• Any task that was not fated to be completed in the next few days, would end up on one of the other three sheets.

Pages 2-4 were each a monthly calendar (the camp only ran for 3 months), with blank boxes for each day.

• Any “future” task would get added to the day on which it needed to be completed.

The true secret to the method, however, was not the paper, pencil, or clipboard, but the daily review! At the end of each day I would rewrite the task list on a new piece of paper, adding the calendar items for the next few days and re-prioritizing the entire set of tasks for the next day.

That’s it.  A frequently reviewed list for immediate tasks and a calendar for future items.  The winning element of the strategy is the frequent review and reassessment of the tasks:

1. A task does not stand alone, but needs to be assessed and prioritized within the context of the other tasks.
2. The re-review re-briefs you on what you need to be thinking about and doing.
3. Reviewing the task list often triggers other tasks that should be added.
4. Reminding yourself that you own your task list can be very satisfying!

The task management “tool” is immaterial and left to personal preference.

My task for next week is to provide some specific pointers for task management success…

• Business Requirements. Written and Approved. Check.
• Functional Requirements. Written and Approved. Check.

Seems like everything is covered. Except… where’s your traceability matrix? You have one, right?

If you don’t, you’re missing one of the best tools for ensuring a successful project.

By creating links – traces – between your business requirements, functional requirements, and test scripts you reveal a number of critical things about your project:

• Is each business requirement being implemented by a functional requirement?
• Is each functional requirement being driven by a business requirement?
• Is each functional requirement covered by a test script?

A full matrix might look something like this:

As you can see, a 1:1:1 ratio between business requirements, functional requirements, and test scripts doesn’t always exist:

• A single business requirement can trace to multiple functional requirements
• A single test script can trace from (“cover”) multiple functional requirements
• Multiple test scripts might be necessary to cover a single functional requirement

What you can also see is that your project has some serious problems.

Without even looking at the actual text of the business or functional requirements, the traceability matrix raises a number of red flags:

• BusReq4 does not trace to a single functional requirement. This reveals a gap in the project’s design.
• FuncReq6 does not trace to a test script. By creating a traceability matrix you can discover and correct a gap like this during the development phase, not during the expensive post-release phase.
• FuncReq7 does not trace from a single business requirement. Hmm…where did this requirement come from? If it’s not driven by a business requirement, what is it doing in this project? This is an indication of possible scope creep.

We’ve just touched the surface of what a traceability matrix can reveal about your project. Future discussions of this topic will probe a little deeper into the rewards and risks of maintaining a traceability matrix.

1. Leadership & organization
2. Business acumen
3. Technical chops

Normally, labor in a project is divided up according to these specialties – i.e. developers have the technical chops, business analysts have the business chops, project managers organize themselves and everyone else. Throw them all into a pot, stir vigorously and…presto! A successful project.

Hardly.

At the heart of every successful project is usually a person or two who seems to posses key slices of at least two of these skill-sets. It could be:

• A project manager who has deep experience in the business domain in which the project is executing, and is able to do double-duty as requirements facilitator.
• A business analyst who understands and appreciates the architectural implications of the solution being implemented, and even knows the enterprise’s technology strategy – a true Business Archtiect.
• An IT Architect who, in addition to having his software patterns down pat, is also a strong leader able to bring warring stakeholders to consensus.

We at Systems Flow long ago recognized the special role these “utility players” have in successful projects.

Over the years we’ve evolved this into a “sacred triangle” of skills that all our consultants are measured against, both during recruiting and in our employee development program:

Even though each individual consultant is usually engaged with a client for one area primarily, we recruit and cross-train all our consultants in each area and consider them core for success. We even have detailed process, guidelines and samples/templates for things as sublime as Logical Design Artifacts, and some things as mundane as meeting recaps.

Contact us to learn more about our process – whether you’re looking for help, or looking to join our team!