Blog - User InExperience

Handling Broken Links With ASP.NET Routing

2009-06-05T19:15:30.727

One of the unfortunate realities of migrating your blog from one engine to another is that you run the risk of leaving a trail of broken links from Google and other external sources if your new engine has a different way of generating URLs for your content than your old engine did. Most do and, as a result, your new engine often gives you the ability to customize your new scheme to a legacy scheme, and things are seamless. Wordpress does this with an admin screen that specifies five options for creating Permalinks to your site, as shown in the screen below.

So if your old blog used a /<year>/<month>/<post> scheme, your new one can too.

But what if you like the new engine’s scheme and you want to use it going forward? You can’t very well serve broken links to people--that would break the internet--so you need to find a way to both leverage the new routing scheme and preserve legacy URLs from external sources.

Enter ASP.NET Routing

Routing is a new feature for ASP.NET that was released in 3.5 SP1 after the MVC team realized that its benefit extended well beyond MVC applications. So, while used most visibly in ASP.NET MVC applications, routing is available to leverage in forms applications as well.

From the MSDN Article (emphasis mine):

“ASP.NET routing enables you to use URLs that do not have to map to specific files in a Web site. Because the URL does not have to map to a file, you can use URLs in a Web application that are descriptive of the user's action and therefore more easily understood by users.

…

In ASP.NET routing, you define URL patterns that contain placeholders for values that are used when you handle URL requests. At run time, the pieces of the URL that follow the application name are parsed into discrete values, based on a URL pattern that you have defined. For example, in the request for http://server/application/Products/show/beverages, the routing parser can pass the values Products, show, and beverages to a handler for the request. In contrast, in a request that is not managed by URL routing, the /Products/show/beverages fragment would be interpreted as the path of a file in the application.”

So, rather than /products/item.aspx?id=2, you can use /products/item/2 or /products/sprocket. In fact, you can use both to route to the same location or action.

(Aside: If you’re thinking, “this sounds similar to what I already have in PHP and Rails,” you would be right. The platform is evolving and taking on new ideas all the time. Now come back to .NET, you know you miss it here.)

Routing and ASP.NET MVC

Bottom line: Routing enables me to define URL patterns for my site and map those patterns to an action that responds to the request. In MVC, which responds to requests rather than events (as ASP.NET Forms does), this means that routing enables me to define URL patterns that map to actions on my controllers and which provide data that the controller needs to pass a model to my views. In the context of MVC, routing is the transit system that ensures that the right Controller and the right Action are found every time.

(Aside two: I’m not going to dive much more into what routing is and will instead show how I’m using into to solve the problem of preserving links after content migration. If you’d like to know more about routing itself, I’d recommend the MSDN article and the “Routes and URLs” chapter in the Wrox Professional ASP.NET MVC 1.0 book.)

What This Means for Content

In my mind, a URL is not just a location of a resource. It’s also:

1) A contract with the user that the thing of value you expect to find is on the other end of this link. A broken link is a broken contract with the user, and should be avoided at all costs. (a rule I’ve broken myself)

2) A key component of the web User Interface (and User Experience). Meaning that a URL like http://awesomesite.com/page?id=0432drtG56689MdRR is no better than presenting the user with this:

The URL is part of the user’s interaction with your site, and it should be designed with the same care as the site layout itself.

The good news is that Routing meets both of these needs nicely.

So I Moved My Blog and Broke Some Links

As I mentioned in my last post, after five years of running this blog on Wordpress, I moved to Oxite, an Open Source content engine built on ASP.NET MVC. I did this knowing that links like this:

http://www.userinexperience.com/2009/02/16/debugging-workflows-wf-tracing-when-nothing-else-works-try-this

Would break as Oxite would use this default URL instead:

http://www.userinexperience.com/Blog/debugging-workflows-wf-tracing-when-nothing-else-works-try-this

With routing, the solution is simple. I simply add something like this to my site RouteCollection (note that MapRoute is an MVC-specific implementation of ASP.NET Routing. Default routing is typically called through the routes.Add() method):

   1:  routes.MapRoute(

   2:     "LegacyUrl",                                  // Route name

   3:     "{year}/{month}/{day}/{postSlug}",            // URL with parameters

   4:     new { controller = "Post", action = "Item"}   // Parameter defaults

   5:  );

Using this pattern, all of my broken links are handled and routed properly (provided that my postSlug value is the same), while giving me the flexibility of new URL patterns going forward.

Making It Work In Oxite

The code above won’t work in Oxite, though. If you want to do something similar in the Alpha version of Oxite (where they are using ASP.NET Routing and not MVC routing), you can add the following to OxiteRoutes.cs:

   1:  AddRoute(

   2:     "LegacyUrl",

   3:     "{year}/{month}/{day}/{slug}/{dataFormat}",

   4:     new { areaName = "Blog", controller = "Post", action = "Item", dataFormat = "" },

   5:     new { dataformat = "(|RSS|ATOM)" },

   6:     new { Namespaces = controllerNamespaces }

   7:  );

AddRoute is a private method that calls the routes.Add() method.

If you’re working with a more-recent version of Oxite, you’ll notice that the engine now uses MVC routing. As such, you can add the following to OxiteRegisterRoutes.cs:

   1:  MapRoute(

   2:     "LegacyUrl",

   3:     "{year}/{month}/{day}/{postSlug}",

   4:     new { areaName = "Blog", controller = "Post", action = "Item", dataFormat = "" },

   5:     new { areaName = new AreaConstraint(container) },

   6:     controllerNamespaces

   7:  );

So It Works, But Can It Be Better?

So problem solved, right? Well, yes, but in the context of Oxite, I’ve made a engine-behavior change to resolve an implementation-specific issue. Not everyone needs to route legacy URLs, and even those who do may or may not need to route those URLs using the exact same pattern that I need. Some might need a completely different scheme altogether.

So this really is no long-term solution. A better solution is a Routing Plugin for Oxite that allows a site administrator to create routes declaratively, using one or more canned options, or defining their own as needed. This would enable both Legacy URL support, and support for additional patterns (vanity URLs, etc).

That’s something I’ll be working on in Oxite soon, and I’ll make the source available here as I’m working on it.

User InExperience Now Powered by ASP.NET MVC and Oxite!

2009-05-26T14:09:29.21

Over the last few months, I’ve been knee-deep in ASP.NET MVC for a client mobile web application. All in all, I’m really impressed with what Microsoft turned out in the 1.0 release of the bits. I have a few posts in the hopper about how we (Thought Ascent) are using MVC to target mobile devices with views customized to platform capabilities, and will be posting those in the coming weeks.

While wandering around ASP.NET MVC-land, I was directed to Oxite, a blogging/CMS platform built on ASP.NET MVC and which leveraged the broad expertise of the guys responsible for Channel 8, Channel 9, Channel 10 and MIX Online. Oxite also powered the sharp-looking Mix 2009 site.

So, after five years of hosting this blog in WordPress, I decided it was time to switch to .NET hosting and Oxite. So far, I love it. The transfer was quick and painless, other than some minor issues with BlogML and encodings on content from the WordPress blog, but everything made it over. I’m happy to finally be on a .NET blog engine and am glad I jumped into Oxite early. It’s an Alpha project as of now, but I’m impressed with the engine and the internals and am looking forward to diving in, tweaking the source on my end and perhaps even contributing to the mainline over time.

Many thanks to Tobin Titus for the sharp-looking theme. One of these days, I should skin my own site…

Links:

ASP.NET MVC

Oxite

Note: If you came here and found a broken link from a referrer, try the search box on the right. I promise everything is still here. I plan to implementing routing to tie those links back together soon. In the meantime, a keyword or two should get you to what you’re looking for.

The Future of Work and Workflow - RMTT Slides and Code Samples

2009-05-26T12:50:27.653

Well, the Rocky Mountain Tech Trifecta has come and gone, and I think the event was a big success. There was a great turnout, and some really useful sessions.

I was pleased to have a full house in my WF talk, and I hope that it was a useful time for those that chose to listen to me drone over the other available options. There was some good interaction and good questions, both during and after the talk.

If you were there, I'd love to hear your feedback, good or bad. I can take, and I'm always looking for tips on how a technical talk can be more useful. If you have unabashed praise, I like that too.

If you would like to have the slides, I've embedded those below, or you can download them here. I have some notes of many of the slides if you're interested in more detail than I shared in the presentation. There are also a few slides at the end on .NET 4.0 improvements to WF that I didn't get to during the talk.

If you would like the code and demos I used during the presentation, you can find everything in a single Zip here. Most everything you need to run the demos should be here, but you will need to create the persistence and tracking databases if you want to use those pieces. Also, you'll need to have MSMQ installed and running on whichever machine you plan to use for these demos. There's a Powershell script to create the queues in the ConsoleWorkflowServiceHost project if you want to try out the MSMQ features.

There's also some unit tests if you want to try things out independent of the web app. You'll need to stage some data, but that's pretty easy. You'll notice that I also added a Test file to test the Custom WF activities I created for this demo separate from the WF itself. This is something I only mentioned in passing in the talk, but it's worth checking out as it's a useful way to really test your custom activities.

If anything else is gnarly, feel free to drop me a comment here or an email and I'd be happy to help you out.

The Future Of Work And Workflow

View more presentations from Brandon Satrom. (tags: wf wcf)

Debugging Workflows: WF Tracing - When Nothing Else Works, Try This...

2009-05-19T15:42:15.523

If you've spent any time with Windows Workflow Foundation, you probably know that every possible thing you can do to enable logging and tracing of your workflows at runtime (Tracking, logging, Tracing) can save your butt when you just can't seem to find out why the heck your workflow is sitting idle after you've just thrown a few hundred concurrent requests at it.

Tracking is pretty well documented, and I would highly recommend it, along with a Monitoring tool that gives you a view into tracking results without needing to write queries against the tracking DB (I'll cover some minor enhancements I made to this tool in another post). Not that it's really that difficult, it's just not worth your time to figure out the ins and outs of the Tracking DB schema when Microsoft plans to greatly enhance it in .NET 4.0. (along with providing Tracking data views in IIS, which will be fantastic.)

Logging, whether via Enterprise Library or another tool like Log4Net, is also pretty well documented. If you're using Workflow Services, you'd also be wise to use Service logging as another source for Workflow forensics. This is also well documented.

Tracing, on the other hand -- which I consider to be the last line of defense when WF Runtime seems fine, Tracking data is clean, but the WF isn't completing as expected and/ or you're seeing intermittent socket exceptions in the svclogs -- is not so well documented. Perhaps this is because it need not be documented as it is simple and I am daft.

In any case, I thought it might be helpful to expound upon a few of the entries I have seen regarding Workflow Tracing.

When I first looked into adding tracing to my Workflow Host, I found several articles that recommended the following code in config:

   1:  <configuration>

   2:    <system.diagnostics>

   3:      <switches>

   4:        <add name="System.Workflow LogToTraceListeners" value="1" />

   5:        <add name="System.Workflow.Runtime.Hosting" value="Verbose" />

   6:        <add name="System.Workflow.Runtime" value="Verbose" />

   7:        <add name="System.Workflow.Runtime.Tracking" value="Verbose" />

   8:        <add name="System.Workflow.Activities" value="Verbose" />

   9:        <add name="System.Workflow.Activities.Rules" value="Verbose" />

  10:      </switches>

  11:    </system.diagnostics>

  12:  </configuration>

I found one example of this on MSDN. The guidance is spot on, but it is missing a few lines that I think would be helpful for a developer at his or her wits end with WF who is just trying to get logging up and running. It goes without saying that "LogToTraceListeners" assumes that one or more trace listeners already exist in your config. They don't exactly tell you that, do they? What's more, the self-contained config above would lead one to believe that you're all set this with this block of code.

Not so. At bare minimum, you'll need to add at least one of the listeners below (unless you wanted to use the EventLog listener, but you get the idea):

   1:  <system.diagnostics>

   2:      <switches>

   3:        <add name="System.Workflow LogToTraceListeners" value="1" />

   4:        <add name="System.Workflow.Runtime" value="Error"/>

   5:        <add name="System.Workflow.Runtime.Hosting" value="Error"/>

   6:        <add name="System.Workflow.Runtime.Tracking" value="Error"/>

   7:        <add name="System.Workflow.Activities" value="Error"/>

   8:        <add name="System.Workflow.Activities.Rules" value="Off"/>

   9:      </switches>

  10:      <trace autoflush="true">

  11:        <listeners>

  12:          <add name="ConsoleTraceListener"

                    type="System.Diagnostics.ConsoleTraceListener" />

  13:          <add name="TextWriterTraceListener"

                    type="System.Diagnostics.TextWriterTraceListener"

                    initializeData="System.Workflow.Trace.log"

                    traceOutputOptions="DateTime" />

  14:        </listeners>

  15:      </trace>

  16:    </system.diagnostics>

Obvious? Maybe, but it's easy to miss in a rush. If that's you, I hope this helped.

You might find that adding those two lines did nothing to fix your issue, in which case I might have something else for you to try. I' have seen in some cases where listeners are already set up for other parts of the system (WCF logging, for example) that the code above still won't work. If that's you, try this:

   3:    <sources>

   4:      <source name="System.Workflow">

   5:        <listeners>

   6:          <add name="System.Workflow" />

   7:        </listeners>

   8:      </source>

   9:      <source name="System.Workflow.Runtime">

  10:          <listeners>

  11:            <add name="System.Workflow" />

  12:          </listeners>

  13:        </source>

  14:        <source name="System.Workflow.Runtime.Hosting">

  15:          <listeners>

  16:            <add name="System.Workflow" />

  17:          </listeners>

  18:        </source>

  19:        <source name="System.Workflow.Runtime.Tracking">

  20:          <listeners>

  21:            <add name="System.Workflow" />

  22:          </listeners>

  23:        </source>

  24:        <source name="System.Workflow.Activities">

  25:          <listeners>

  26:            <add name="System.Workflow" />

  27:          </listeners>

  28:        </source>

  29:    </sources>

  30:    <sharedListeners>

  31:      <add name="System.Workflow"

                type="System.Diagnostics.TextWriterTraceListener"

                initializeData="c:\logs\System.Workflow.trace.log"

                traceOutputOptions="DateTime" />

  32:    </sharedListeners>

  33:    <switches>

  34:      <add name="System.Workflow.Runtime" value="Error" />

  35:      <add name="System.Workflow.Runtime.Hosting" value="Error" />

  36:      <add name="System.Workflow.Runtime.Tracking" value="Error" />

  37:      <add name="System.Workflow.Activities" value="Error" />

  38:      <add name="System.Workflow.Activities.Rules" value="Off" />

  39:    </switches>

Notice that live 4 in the first example is nowhere to be found here. I found I didn't need it. You'll also note that I had to add a source and listener for each Namespace in System.Workflow that I wanted to trace. I can't say why this works in cases where existing sources cause the "LogToTraceListeners" switch to hit the fritz, but I thought it was worth sharing. If it gets you our of a jam, then I'm happy to have shared it.

The Future of Work and Workflow - Speaking at the Rocky Mountain Tech Trifecta on Feb. 21st

2009-05-19T15:42:15.137

If you've read this blog for any length of time where I've posted regularly, you'll know that I'm a pretty big wonk for composition, Composite Apps and all things assembled and reused over coding from scratch.

So it should be no surprise that I'm quite a fan of Windows Workflow Foundation (WF), the Chico Marx of the .NET Framework, underappreciated for it's elegance, simplicity and power to fundamentally change the way that applications are built in the future. Wait, that last part doesn't quite apply to a lesser-known Marx brother, but you get the idea.

I've been interested in WF (If you hear me speak about it, notice that I will never, ever call it "Dub-F." Can't do it.) from the beginning, and have spent the last four months swimming in the deep end with WF, building some key pieces of an integration layer for a payment processing system that Thought Ascent has been working on for some time. Over that time, I've discovered that WF really does have all of the potential I suspected it did, and then some.

WF is a platform that will change the way we look at building applications, and I think that WF is a great example of the kinds of technologies that will move us closer and closer to true composition of applications over the next 5-7 years. Of course, being a Workflow platform released in concert with a universal framework for building connected systems (WCF) and the UI framework of the future (WPF) sort of makes Workflow Foundation like the third member of Destiny's Child. Those other technologies were game changers from day one. WF has an uphill battle to fight for recognition and adoption, but I believe it's the game changer of the future.

Not that it's being ignored, I just think it's been undervalued in the past, typically met with comments from developers and architects like "I get how it works, I just don't see what it's for"or "what does this give me that I can't do myself with code?"

But I see that tone changing, with Microsoft putting a better and better case around Workflow though integration with key technologies, along with richer complimentary services and tighter integrations with WCF.

So why am I telling you all this?

As you may or may not know, the Rocky Mountain Tech Trifecta is coming up in Denver on February 21st. This event will bring together several experts in the world of .NET, SQL and Windows, along with a few wannabees like myself who will present on just about anything you could hope to hear about in a developers conference. And there will be some heavy hitters to be sure: Scott Hanselman, Paul Neilsen, Rob Bagby and others. I'm not worthy...

If you hadnt't guessed from the first paragraphs of this post, I'll be speaking on Windows Workflow Foundation. Here's the abstract for the talk:

The Future of Work and Workflow

Since .NET 3.0, Windows Workflow Foundation (WF) has lived in the shadow of its flashy framework companions WCF and WPF. Yet from the start WF has been, at its core, about new ways of creating durable applications and composable units of work, both of which have the potential to change the way that developers assemble solutions. In this talk, Brandon will cover some of the highlights and recent enhancements to WF (Creating workflow services with WCF and WF, Workflow Persistence and Tracking), tips and tricks for advanced workflow scenarios (using MSMQ with workflow services, custom activities, etc.), and a preview of some upcoming Workflow features in the 4.0 Framework.

If you're close to Denver and haven't signed up yet, you can sign up at www.rmtechtrifecta.com. And if you're planning on coming, drop me a line. It should be a fun day.

And if you're not planning on coming, look for slides and code here over the next few weeks.

Job Changes, Blog Changes

2009-05-19T15:42:14.907

So I've up and switched jobs.

After four years, over two of those as an Enterprise Architect, I've bid goodbye to Compassion and am re-entering the world of consulting.

I loved my job at Compassion. There were many challenges, but there were many great victories and joyful seasons. And I'd like to think I helped contribute to some of the recent successes for both IT and the burgeoning EA group. For example:

1) Moving EA Out - The value of EA has been recognized at the executive-level, mostly due to the tireless efforts of my boss over the last six years. For the last two, I've tried to help in any way I could. As a result of this new success and visibility, the EA group will be moving out of IT and into the Global Strategy organization at Compassion. EA moving out of IT is a trend that Gartner is noting with increased frequency, and I am excited to think that the Compassion EA group will be among the first to align itself with the business WHILE maintaining a strong connection with IT.

2) Architects, Architects Everywhere - Over the last two years, we've been working to evangelize the need for more architect-level positions throughout the IT organization. This summer, those positions were added to the organization as a part of an IT-wide restructure that just wrapped a few months ago. Since then, I've been working with these new domain architects and have been very impressed at the talent and skill they bring to the organization. Their presence will aid Compassion greatly in the future, and I'm happy to have had a chance to work with them, even if for a short time.

3) A Vision for the Future - Last year, I wrote several posts on a vision for Composite applications that we were calling the Composite Application Framework, or CAF. (Apparently I need to find out what happened to all the images in my older posts) Since we authored that vision, it has been adopted by the organization and IT has been building the foundation of the CAF for nearly a year. Even though I'm an outsider to the process now, I'm excited as a sponsor of three Compassion children to see how that vision enhances the ability of the ministry to reach both children and sponsors. Take it from me, I think it's gonna be awesome.

And in spite of all of that, and a million other fantastic things I've been blessed to be a part of, I've been called elsewhere.

As of today, I'm a Practice Architect for Thought Ascent, Inc. a IT consulting and services company based in Colorado Springs. There were a lot of reasons for my taking the job, but suffice it to say that I've been offered an opportunity that aligns with my goals and desires, both personally and professionally, so I jumped at the chance. It was tough to leave such a great organization, and one that is doing such amazing things, but I know that they'll continue to do well and I can't wait to see the amazing impact that Compassion continues to have in releasing children from poverty around the globe.

So what does this mean for the blog, you ask? (Or perhaps I just pretend you ask)

I'll ~~keep~~ resume blogging, for one thing. And while I still plan to talk about Enterprise-scale Architecture, I'll be mixing in a healthy dose of code from the .NET world. That said, expect that I'll spend less time talking about EA as a management discipline and more time talking about EA as a framework for solution delivery.

Bottom line, the initial goal of User InExperience remains the same: To document the thoughts and discoveries of this (mostly inexperienced) wanderer as he navigates the nooks and crannies of of technology and often finds himself in the right place at the right time.

How's that for establishing authority? In any case, I hope you'll stick around.

New Site Design and New Content Coming

2009-05-19T15:42:14.11

My recent inattention to this blog is quite shameful, so it's time for an overhaul.

For starters, I've updated the site design to something cleaner, brighter and with more real-estate. I feel better already. I hope you do too... still need to re-upload some lost images.

I also plan to spend more time in the coming months on Solution Architecture and design, along with the practical aspects of strategy and solution architecture, and less energy on the EA as IT management, which has been the focus of my day-to-day life for the past several months, and the tone of some recent posts. I use the term "recent" loosely...

Have a great weekend. Thought, comments and suggestions on content and design are always welcome.

Embracing the Long Tail

2009-05-19T15:42:13.533

Note: This is the second post in my Freedom within a Framework series, which is about enabling the coexistence of enterprise and opportunistic applications. You can read the introductory post here.

As I stated in my introductory post, I believe that it is possible to achieve a balance between the need for stability in enterprise applications, and the need for quick and agile innovation in opportunistic applications. They key to this balance lies is in determining where the domain of control for IT can safely transition into a environment of open access to information. This is a "line of demarcation" that allows for a clean separation of certain types of applications. The best way to picture this concept is to imagine a line on an X-axis, with control of technology at the left side, and anarchy at the right. "Command and Control IT" typically lives as close to the left as is possible, while the world of "consumer-driven IT" lives quite far to the right. There are opposed to be sure, but it is possible for IT to reconcile these differences and foster both sides by creating a shared understanding around which classes applications should be enterprise-class and which can and should be treated as opportunistic.

Another way to visualize this concept is with the "Long Tail," which is depicted in Figure 1 below. The "Long Tail" was a term coined by Chris Anderson in Wired Magazine to describe how the business models of companies like Amazon or Netflix enables them to profitably offer a wider range of goods and services than traditional organizations. The concept (also referred to as a heavy-tail or Pareto distribution) is a well-known statistical occurrence where a high-frequency population (depicted by the region in green below) is followed by a very long low-frequency population that gradually diminishes in area (or "tails off"). In many cases, the long tail portion of the graph, colored in yellow below, can actually represent the majority of the area under the line in the graph, even though the frequency is lower along that portion of the line than it is in the green area.

Figure 1 - The Long Tail

When applied to Amazon and Netflix, this concept is used to illustrate that organizations with powerful distribution channels can make just as much or more selling ten copies each of 10,000 obscure books as they could selling 100,000 copies of one best-selling book. The application to many organizations is just as powerful when information is the product. Assume for a moment that the green portion of the graph represents enterprise-class applications with a large internal user base and the "long tail" or yellow portion represents opportunistic applications with a much smaller number of users. This is depicted in figure 2 below.

Figure 2 - The Long Tail for Applications

In this scenario, the "long tail" theory argues that an organization could serve more users with several hundred opportunistic applications than it does with a small number of enterprise-class applications, but at a much lower cost. Thus, a "long tail" model can enable an information-driven organization to serve its customer base effectively without greatly increasing the cost of software delivery. Such a model does so by enabling the kinds of opportunistic development which most IT organizations would likely never have the bandwidth or justification to pursue because they are applications which are tactical in nature and which may only serve a small number of users.

While a "Long Tail" mindset enables us to create a clear line of demarcation, simply classifying one type of application or information set as enterprise and another as opportunistic isn't enough. It is entirely possible for IT to pursue this demarcation with good intentions, and then stifle innovation by requiring that all applications, including opportunistic ones, be developed using only one type of platform or programming language. Thus, another key to creating "Freedom within a Framework" is that IT must give up as much control as is possible, while at the same time recognizing the assets and information over which the enterprise should retain control. In my next post, I'll discuss the concept of an IFaP architecture which, I believe, provides a powerful architecture for enabling open innovation while, at the same time, providing IT with a framework to manage its information assets.

Technorati Tags: REST, Web 2.0, Enterprise Architecture, EA, Long Tail

Visualizing The Interactions of Enterprise Architecture

2009-05-19T15:42:12.953

Okay quick question, assuming I have any readers left after my far-too-long hiatus.

Assume that the middle box--labeled "Translation"--is EA.

With no explanation from me, what does this graphic mean to you?

What do you think it says that you would agree with?

What does it say that you would dispute?

Interested in hearing your thoughts...

Yes. We. Can.

2009-05-19T15:42:12.673

It's Super Tuesday. Time to get down to the business of choosing our candidates. If you're in a state voting today, I hope you'll be there. For now, check this out. (Links to my "other" blog) Happy Super Tuesday! - Brandon

Freedom within a Framework (or FRED) Introduction

2009-05-19T15:42:11.787

For the past several weeks, we've been working on creating a viewpoint of our future-state architecture that enables a greater degree of low-hurdle innovation with technology than we currently enable. The goal is to enable anyone across the globe, inside of the organization or out, to make use of public information we provide to create applications of value, even if that value is only seen by a single individual. Call it Web 2.0; Call it Enterprise 2.0. Call it what you will. We're calling it either Freedom within a Framework or the Framework for Rapid and Empowering Development (FRED) depending on to whom we're currently pitching the idea. The latter is our EA marketing savvy at work...

The idea is simple: We want to create an environment when enterprise applications can be created and managed in an enterprise way, and opportunistic applications (i.e. ad-hoc process applications and mashups) can be created freely and with little to no involvement from the IT organization. IT does what it does best, but explicitly steps back from "owning" all information and technology in an organization. From concept to implementation, I believe that one way to foster such an environment is to allow the world of WS-* and the world of REST to co-exist within the enterprise. Rather than an either/or decision, we want enable and encourage both styles for certain types of situations.

The culmination of our work around this idea was a paper published internally at the end of November, along with a demo that provides an example RESTful interface (which depends on our existing SOA) and a couple of applications which consume information presented by those interfaces.

Over the next few weeks, I plan to post excerpts from this paper and some of the meat from the demos. My intent in doing so is twofold:

1) To posit an alternative to the REST vs. WS-* debate. I am certainly not the first to argue for cohabitation of these styles. I only wish to add my voice and provide another perspective.

2) To obtain feedback from Enterprise and SOA Architects who have either already considered, are considering, or have implemented a similar design. I'd love to hear feedback in the coming weeks from anyone wanting to way in on any of the topics below.

I'll publish the first post tomorrow, and the subsequent ones every couple of days after that. Here are the topics I plan to post about, in order:

Embracing the Long Tail
IFaPs: Enabling the Long Tail and Protecting the Enterprise
REST: The Entry Point for Innovation
Benefits of a RESTful Interface
REST and Security
A Demo RESTful Interface
Demo Opportunistic Applications

As I add posts, I'll return to this post and add the hyperlinks.

Looking forward to the discussion!

Technorati Tags: REST, WS-*, SOA, Enterprise Architecture, EA, Web 2.0, Mashups

Do Enterprise Architects Care (Enough) About Security?

2009-05-19T15:42:11.587

I'm sitting in a session at the Gartner EA Summit entitled "Security Architecture Best Practices." I'll be the first to admit that I don't pay enough attention to the Security side of Enterprise Architecture, which is why I am in this session and plan on attending another complementary session tomorrow. I am surprised to see that, though there are 600 people at this portion of the Summit, there are only about 50 people in this room. So is EA really that far behind the curve in getting on board with Security? What are we all doing beyond adding a vertical "Security" bar to our models? Not much, in my case, but I am feeling that that ought to change, especially in light of some things I am starting to work on which I will blog more about in the coming weeks.

I know that James McGovern cares about security. In fact, he has stated before that he sees it as a form of competitive advantage, which, if true, explains why there are only 50 people in this room. I would expect that to grow year by year.

As for the session itself, so far so good. One salient point that I've heard Gartner preach before, but am now seeing tied to the Security space is that the "Consumerization of IT" should lead us to drive our Security Architecture and Design to enable choice and distributable trust. Personally, I feel that lock down security, the knee-jerk of most Enterprises, is an over-engineering step that will leave us inflexible and closed off from a younger generation of employees and consumers. Thus, I'm glad to see that backed up with some analysis from Gartner.

I'm glad to see Gartner offering sessions such as this in to an EA audience. My advice to them is to continue to offer sessions like this, even if the attendance from this year's summit doesn't suggest that there is an interest. Those numbers will grow.

Technorati Tags: EA, Enterprise Architecture, Security, Gartner

MS Architecture Journal Reader

2009-05-19T15:42:11.293

The Microsoft Architecture Journal has been one of my favorite print periodicals lately. The articles are top-notch, relevant and very well-written. If you don't have a subscription, I would highly recommend it, even if you're not in an MS shop. Yes, there is a Microsoft bent, but there are also some gems that, I feel, have been universally relevant.

I noticed in Simon Guest's blog this morning, that Microsoft has released an Architecture Journal Reader that provides digital access to all thirteen issues of the journal, with search, favorites, annotation, etc. I've already downloaded it and It will be nice to have all of that information closer at hand. You can download a beta of the reader here, and go check out Simon's post here.

Technorati Tags: Microsoft, Architecture Journal, Architecture Journal Reader, WPF

Tell me where your SOA Hurts...

2009-05-19T15:42:10.89

...and I'll charge you an arm and a leg to make it better. Looks like IBM is starting up a dysfunctional SOA practice. Not surprising really. Consider this quote: "Some organizations may not be happy with their service oriented architectures (SOAs). They may have "unhealthy" SOAs as a consequence of partnering with inexperienced system integrators. They may have proprietary SOA technology in the mix, and it may be difficult to scale operations."

They will probably make a killing since no one agrees on what SOA really means and all IBM has to do is figure out what you think it is, then convince a few key executives that that's the wrong idea, thus rendering them instantly unhappy. It was bad enough when selling the buzzword ruled the day, but selling the band-aid will be worse, I fear. This, my friends, is why we never should have let our executives hear "SOA" in the first place.

Here's a question: what happens if an organization worked with IBM as their Systems integrator in the first place and is now unhappy with what they got? Would IBM ride in to rescue that organization too? <unrealistic>Maybe for the sake of good-will and a case-study, they'd do it for free.</unrealistic> I wonder how IBM would sell that engagement? Probably by blaming your internal management.

I can't help but think that this is a case of selling me poison, then following that up by telling me I have a deadly poison in my system and that you just so happen to have the antidote. Not that I am calling SOA poison in any way. Conceptually, it's just the opposite.

Maybe I'm overreacting or being too negative here. Any one care to chime in with excitement about this announcement?

Technorati Tags: SOA, IBM, EA, Enterprise Architecture

Gartner Architecture Summits

2009-05-19T15:42:10.417

From December 3-7, Gartner will be holding two back-to-back summits on Application Architecture, Development and Integration and Enterprise Architecture at the Rio in Last Vegas. It looks to be a informative week with some valuable sessions and insight. Todd Biske will be there in two panel discussions and I am looking forward to both of those, along with a number of others currently on the agenda.

Aside from the sessions, I've found that I gain the most value from these events when I have a chance to interact with other attendees. Are any other folks reading this planning to attend? If so, drop me a line in the comment section or via email at bsatrom at gmail dot com and we can try to connect during the week. I am always looking to gain the perspective of others in the opportunities and challenges that my EA group faces, as well as hear about the exciting and innovative things that other enterprises are doing. Hope to see you there!

Technorati Tags: Gartner, Enterprise Architecture, EA, SOA, Application Architecture, Architecture

Using Technology to Fight Poverty: OLPC and Give 1 Get 1

2009-05-19T15:42:10.06

In my last post, I spoke briefly about posting from time to time on the topic of technology that plays a role in fighting poverty. I figured that a good place to start with would be the One Laptop Per Child (OLPC) program, probably the most notable example of such. There's not much I can say about this highly-publicized program that hasn't already been said or written elsewhere, so I'll just share a couple of resources I have come across recently.

For starters, Ivan Krstic, the Director of Security Architecture for OLPC gave a great talk on the technical ins and outs of the XO Laptop at Google back in April. You can check it out here. It's an hour long, but worth a watch. (Thanks for Phil for pointing this out to me).

Of course, the biggest news in the XO Laptop department is the Give 1 Get 1 Program, which officially begins at 6 AM Eastern tomorrow. (BTW, the OLPC news site is a great resource for exactly that) The gist of the program is this: You pay $399 for two XO Laptops. You get one and the other is sent to a child in a developing country. T-Mobile has jumped into this promotion by throwing in a year of free T-Mobile Hot Spot access for the donor and EA is graciously donating the original Sim City to be included on all of the laptops.

Professionally, I am interested in Give 1 Get 1 because it seems to have potential to enhance the 1-to-1 model of child sponsorship that Compassion has held to for over 50 years. Imagine the impact of a sponsor purchasing one of these laptops, then designating that the other be delivered as a gift to his or her child. I don't know if this is possible, probable or neither at this point, but I have contacted Ivan Krstic to ask and I am at least looking forward to hearing a bit more on OLPCs future plans for partnering with international non-profits that have similar goals to OLPC.

If you haven't seen or read much about the program yet, I would encourage you to go check it out. The work that OLPC is doing is pretty amazing on several fronts: they are pushing the hardware and software envelope, all while providing affordable technology with the goal of improving education and peer learning. I, for one, am excited to continue to watch the program and its impact evolve.

Technorati Tags: OLPC, XO Laptop, Compassion, Technology, Poverty

Using Technology to Fight Poverty

2009-05-19T15:42:09.86

I haven't blogged much about technology as it relates to eliminating global poverty, mainly because it's hard for me to do so without talking about the organization for which I work. As has been discussed in the past by Todd Biske, James McGovern and others, corporate bloggers have to be careful to separate our own opinions and stances from those of our organization. Thus, it makes it tricky to talk much about our employers in much detail.

However, I think that putting a gag on myself regarding all issues related to global poverty is a bit extreme. Furthermore, I think that I'm in a reasonable position as an Enterprise Architect working for a non-profit that serves nearly one million children in poverty around the world to try to bring to bear a technology and EA perspective that is shaped by using those tools in that fight against poverty.

I think it's a perspective that is needed, mainly because some people that I encounter in the EA space are surprised to hear that my organization has any kind of IT organization, much less one with an Enterprise Architecture group. I believe a common assumption is that when the main concern is the bottom line and profit, innovative and mature IT is acceptable, if not vital. The unspoken subtext, of course, is that non-profits have no business dealing with (too much) technology strategy and innovation because we do not deal in profit or competitive advantage (I actually think we do deal in competitive advantage, just not in the way you might think... more on that another day). However, a robust and healthy IT organization that is fully aligned to its business is even more important in the non-profit world, simply because the stakes are higher. Not in terms of profits and jobs, but in terms of lives and quality of life. And I honestly don't think that I am dramatizing the issue here, though please chime in if you think I am. I am quite passionate about the subject and might need a cooler head from time to time.

I enjoy the fact that James McGovern increasingly uses his blog to raise our awareness about poverty and to influence others to give to worthy causes. My desire is to add a dimension to my own blog that takes a step beyond "knowing" and "giving" to what we are "doing" with technology in the name of wiping out poverty around the globe. And not just in my organization, either. I think that there are many organizations and individuals out there doing amazing things with technology where the benefit is not a personal bonus or a shareholder dividend; it is a child who can read and write, a mother who can start a business to feed her family, or a saved life.

Thus, I plan to, from time to time, post articles, links and thoughts under the banner of "Using Technology to Fight Poverty." I might even, on occasion, discuss the work my organization is doing because I am sure that there are those out there interested in where we are going with technology. Furthermore, we know that there are thousands of brilliant people involved in technology that already support our cause and would be interested in knowing what more they can do to help us. However, please keep in mind that anything I discuss around these topics is and always will be solely my opinion and may or may not reflect the opinion of my employer. That actually goes for anything on my blog, but it bears repeating.

So, keep and eye out for some more posts with this heading. This should be fun...

Technorati Tags: Business Architecture, Technology, Poverty, IT

Oslo - Microsoft's Strategy for Composite Applications

2009-05-19T15:42:09.553

Last week, Jean-Jacques Dubray published an article on InfoQ regarding Microsoft's recent announcement of Oslo, a strategy designed to "...take composite applications to the mainstream." Rather than revolving around a single product, Oslo sets strategic direction for Visual Studio, BizTalk, the .Net Framework, Microsoft System Center and a new product called BizTalk Services. On a side note: Arnon Rotem-Gal-Oz hopes that this final project's association with BizTalk is more about branding than actual product similarity, a sentiment I share.

After posting this article, Jean-Jacques sent me an email and asked me to share some of my thoughts on Olso for a follow-up article to be published at InfoQ. I sent my thoughts along on Friday, but thought that I would post them here as well.

When we developed a long-term strategy for Composite Applications at my organization, it was obvious that while Microsoft technologies would have a major role to play in many areas of our future-state architecture, there were several vital pieces missing in the Microsoft stack that we would likely need to find elsewhere. I've always felt that we weren't alone in that sentiment, and the Oslo announcement suggests that Microsoft is also well aware of the gaps in their current offerings. While products like Dynamics CRM and MOSS 2007 offer composition scenarios which I regularly point to as examples of end-user and/ or business analyst composition, Microsoft has long been missing the technologies to unify these experiences under a common framework. Though missing in the products themselves, the Composite Applications vision is one that I have seen preached by Microsoft Architects and blogger's like Mike Walker and others who seem to have a good grasp on the long-term potential of composite applications. The good news about the Oslo announcement is that those individuals are no longer in the minority. With Oslo, I believe Microsoft has unveiled merely the beginning of a unification strategy that enables composite applications. I believe that this bodes well for clients and non-clients of Microsoft alike.

That being said, There are two reasons why I'm a bit skeptical about the Oslo announcement: For starters, I believe that Microsoft's stated vision for Composite Applications is too narrow. While the Software + Services and SOA visions are needed, I believe that the end goal of any Composite Applications strategy should be to gradually enable composition up the stack toward the end-user. This is done first by providing a SOA which enables true service and process composition, then by extending those principles to developers of customer applications, business analysts and, ultimately, end users. Oslo speaks well to the former, but the latter is auspiciously missing. I actually don't believe that such a goal is absent in the halls of Microsoft, but I do believe that it hasn't permeated across the organization and thus, isn't given a place in the conversation yet.

The second reason I am hesitant to praise Microsoft for the Oslo vision is because their announcement is related to technologies which are anywhere from 1 year to 3 years or more away from release. Most of the tool updates are two releases away. Microsoft is correct when they say in their press releases that 21st century business is moving faster than IT can deliver, but that statement is true today. Organizations need solutions today, not announcements of solutions coming tomorrow. My organization, for example, cannot wait for a repository to manage models, metadata and services (one of the gaps we knew about in our strategy) when our ability to manage all three is already beyond our control. I honestly believe that Microsoft's vision for Oslo is a good one, but they are just now announcing plans to provide functionality that most organizations already know they need, which puts them at a disadvantage with those organizations. I can see a day in my company where many of the pieces in the Oslo stack make their way into our architecture, but today we need to keep moving. Of course, the good news is that when SOA and composite applications are done right, vendor lock-in is reduced and organizations can focus on delivering for the business today instead of waiting for the remaining puzzle pieces to fall in place tomorrow.

Technorati Tags: Oslo, BizTalk, BizTalk Services, Visual Studio, Microsoft SystemCenter, SOA, Composite Applications, Software + Services

The Fifth Beatle of Composite Application Developers

2009-05-19T15:42:09.147

Back in September, I published a couple of excerpts from an internal paper I wrote on Composite Applications (you can read them here, here and here). At the end of my second post, (which I probably should have broken up into 2-3 posts at least) I discussed the four types of Application Composers. If you missed that section, (which would be proof that I should have broken them up) here's a recap:

1) Business Service Developers - These are IT developers focused on providing value-added common business services to all customer solutions teams. Their technical depth is high and a CAF targeted at these users would be similar to what is provided by SOA today.

2) Customer Solution Developers - These are IT developers focused on creating customer-centric solutions by leveraging software infrastructure. Their technical depth is moderate to high and a CAF targeted at these users would need to abstract away service creation and assembly.

3) Business Analysts - These are customer consultants focused on helping customers determine which business needs are best met with technology. Their technical depth is moderate and a CAF targeted at these users would draw many features from current BPM platforms.

4) End Users - These are the users of the solutions created by customer solutions teams. Their technical depth is low and a CAF targeted at these users would need to abstract away nearly all of the technical aspects of application creation and should provide very intuitive context- and metadata-driven methods for application assembly and customization.

While these still make sense to me, I think I completely missed number five on this list. It's a bit of a wildcard, and it may not apply to every organization, but I think it will apply to more and more organization in the coming years. Here it is:

5) External Developers - These are developers who reside outside of one's own IT organization, but who have development expertise that they wish to leverage to create value-added services that benefit your organization. Their primary interest is in consuming available organizational data and recombining this data with external data or services to create new composites not offered or envisioned by the organization itself.

Now I think that the reason I missed this was because I was thinking internal only when laying out a strategy for Composite Applications in my organization. However, my fearless leader and I have been talking at length about creating a framework by which certain subsets of our information (the right information, of course) could be made available to anyone with the wherewithal to create useful services that we never thought of. Thus, our framework for Composite Applications now has another persona to enable.

So what do you think? Is this a valid addition, or did I have it encompassed in another one of the four? Furthermore, is just one more enough? That fifth category encompasses a ton of people, so do I need another for the technically savvy end user who doesn't write code, but who screams at creating inventive Yahoo! Pipes applications. I suspect that #4 could represent this individual with a slight modification, but what do you think?

Technorati Tags: Composite Applications, SOA, Web 2.0

Using Windows Workflow Foundation to SMS-Enable MOSS

2009-05-19T15:42:08.803

For the past couple of weeks, I have been doing an in-depth look at various mobile communication technologies (SMS, EMS, MMS, etc.) for the purposes of incorporating these technologies into our existing strategies. While the scenarios vary, most of the use-cases driving us to SMS et al. revolve around information delivery in areas where Internet connectivity is problematic, yet cell phones abound. It sounds counter-intuitive maybe, but in many regions (like Africa for example), it's far easier to put up a cell tower than it is to lay cable of any kind. Thus, mobile technology can be found in many places where land lines and Internet access cannot.

Being the agenda-pusher that I am, I can't pass up an opportunity to integrate this technology study with work I have already done and am doing. Since my biggest interest right now is in the Composite Applications space, I wanted to use one of the demos in this study to prove out (to some degree) the composition argument I have been making both in this blog and internally. Thus, I created a demo scenario for this study that sends a 1-way, application-originated SMS Text Message through an SMS Gateway (Clickatell in this case) to a mobile subscriber when a particular field on a list in MOSS is changed. Now, this scenario isn't rocket science, nor is it earth-shattering. What it is, however, is me taking my own medicine. If I'm going to preach the Composite Applications gospel, I'd better try it on for size myself. Here's how I implemented the scenario:

I started by creating a stand-alone custom activity in Windows Workflow Foundation. The code, with some key details removed, is included below. Note: In order use this yourself, you'll need access to an SMS Gateway (like Clickatell, which is used here) and access to their HTTP API, if they have one. Not the only way to send a text message, I know, but SS7 Gateways can provide guaranteed message delivery to the subscriber.

using System;
using System.ComponentModel;
using System.IO;
using System.Net;
using System.Text;
using System.Workflow.ComponentModel;
using System.Workflow.ComponentModel.Design;

namespace MyCompany.Workflow.Messaging.Activities
{
    public class SendSMSActivity : Activity
    {
        public static DependencyProperty NumberProperty = 
            DependencyProperty.Register("Number", typeof(System.String), 
            typeof(SendSMSActivity));
        public static DependencyProperty MessageProperty = 
            DependencyProperty.Register("Message", typeof(System.String), 
            typeof(SendSMSActivity));
        
        [DesignerSerializationVisibilityAttribute
            (DesignerSerializationVisibility.Visible)]
        [BrowsableAttribute(true)]
        [DescriptionAttribute("Destination number of SMS message")]
        [CategoryAttribute("SendSMSActivity Number Property")]
        public string Number
        {
            get
            {
                return ((string)(base.GetValue(SendSMSActivity.NumberProperty)));
            }
            set
            {
                base.SetValue(SendSMSActivity.NumberProperty, value);
            }
        }

        [DesignerSerializationVisibilityAttribute
            (DesignerSerializationVisibility.Visible)]
        [BrowsableAttribute(true)]
        [DescriptionAttribute("Text of SMS message")]
        [CategoryAttribute("SendSMSActivity Message Property")]
        public string Message
        {
            get
            {
                return ((string)(base.GetValue(SendSMSActivity.MessageProperty)));
            }
            set
            {
                base.SetValue(SendSMSActivity.MessageProperty, value);
            }
        }
        
        protected override ActivityExecutionStatus 
            Execute(ActivityExecutionContext context)
        {
            string response;
            
            try
            {
                // Send the SMS Message
                response = SendSMS(Number, Message);
            }
            catch (Exception e)
            {
                response = e.Message;
            }

            // Raise the PageFinished event back to the host
            messageSentEvent(null, new MessageSentEventArgs(response));
                     
            // Notify the runtime that the activity has finished
            return ActivityExecutionStatus.Closed;
        }

        public delegate void MessageSentEventHandler(object sender, 
            MessageSentEventArgs e);

        private event MessageSentEventHandler messageSentEvent;
        public event MessageSentEventHandler MessageSent
        {
            add
            {
                messageSentEvent += value;
            }
            remove
            {
                messageSentEvent -= value;
            }
        }

        public string SendSMS(string number, string text)
        {
            WebClient apiRequest = new WebClient();
            apiRequest.Credentials = CredentialCache.DefaultCredentials;

            //Add a user agent header in case the requested URI contains a query
            apiRequest.Headers.Add("user-agent", 
            "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR 2.0.50727;)");

            //Add the SMS details to the apiRequest object
            apiRequest.QueryString.Add("user", "xxxxx");
            apiRequest.QueryString.Add("password", "xxxxx");
            apiRequest.QueryString.Add("api_id", "xxxxx");
            apiRequest.QueryString.Add("to", number);
            apiRequest.QueryString.Add("text", text);

            string baseURI = "http://api.clickatell.com/http/sendmsg";

            Stream responseStream = apiRequest.OpenRead(baseURI);
            StreamReader reader = new StreamReader(responseStream);
            string responseCode = reader.ReadToEnd();

            //Clean up in-memory objects
            reader.Close();
            responseStream.Close();

            return (responseCode);
        }
    }

    public class MessageSentEventArgs
    {
        private string response;
        public string Response
        {
            get { return response; }
        }

        public MessageSentEventArgs(string response)
        {
            this.response = response;
        }
    }
}

Like I said, nothing earth-shattering. However (and I won't go into the details of WF here as there are plenty of good resources that do that) the end-result is a stand-alone Workflow Foundation Activity which encapsulates the business logic for distributing an SMS Text Message via our Gateway provider and which can be hosted in any application that provides the WF runtime. This Activity can easily be dropped into a container Sequential or State-Machine Workflow project (as I did when testing this activity on my machine), or it can be deployed to MOSS as a stand-alone activity which can be included in a Workflow built using SharePoint Designer. Two scenarios with different composers, both using the same asset. That's the vision of Composite Applications. (As an aside, with the recent Oslo announcement, I imagine that we're not far from a day where that same activity could be also be reused in BizTalk and Microsoft CRM, among others).

So what do those scenarios look like? For the developer adding a custom activity to a WF Workflow, it's a simple matter of dragging the activity from the Toolbox to the designer, then binding to the DependencyProperties (Number and Message in this case) and creating an event-handler to receive the event raised by the activity (in this case, sendSMSActivity_MessageSent). See the image below for an example:

For an individual slinging SharePoint Designer, the experience is different, but also quite powerful. However, The first step I must take as an activity developer is to deploy said activity to the MOSS server. This requires deploying the Activity assembly to the GAC on the MOSS server, adding said assembly as a safe control in the web.config file, and adding the Activity to the WSS.actions file (or a new .actions file in the same directory, which is probably a better idea), which SharePoint designer uses to load up the list of available workflow actions. All of this can be done via a feature in SharePoint (I know that the first two can and I think that the last can, so feel free to comment if I am incorrect). Here is the code for the WSS.ACTIONS file (Added in the <Actions> section):

<Action Name="Send an SMS Text Message"
  ClassName="MyCompany.Workflow.Messaging.Activities.SendSMSActivity"
  Assembly="MyCompany.Workflow.Messaging.Activities, Version=1.0.0.0, 
    Culture=neutral, PublicKeyToken=fe2315b70tbc147c"
  AppliesTo="all"
  Category="Messaging Actions">
  <RuleDesigner Sentence="Send %1 to number %2">
    <FieldBind Field="Message" Text="this message" DesignerType="TextBox" Id="1"/>
    <FieldBind Field="Number" Text="this number" DesignerType="TextBox" Id="2"/>
  </RuleDesigner>
  <Parameters>
    <Parameter Name="Number" Type="System.String, mscorlib" Direction="In" />
    <Parameter Name="Message" Type="System.String, mscorlib" Direction="In" />
  </Parameters>
</Action>

Once that entry has been added, the activity is ready to be included in an SP Designer workflow. In this example, I bound the workflow to a custom list created in a demo site, set a condition to check the value of a key field, then added the "Send SMS Message" activity and configured its inputs. In this case, the message is constructed from existing information in the list and the destination number is determined by looking up the mobile phone of a user in another list. An image of the Workflow Designer Wizard in SP Designer can be seen below:

If the workflow validates, we're in business and the activity will run each time a list item is added or updated and the field in question isn't blank. Here is the Workflows application page, as seen from MOSS itself:

In addition, that activity is now available to include in any workflow where sending an SMS notification is a requirement. You be the judge if this is a blessing or a curse... In either case my hope is that this post illustrates the power of composition. And MOSS is just an example in this case, not the end-all for composition by any means. What important in any composition scenario is a platform and technologies that provide the ability to create reusable assets and then reuse those assets across tiers and containers.

Technorati Tags: Windows Workflow Foundation, MOSS 2007, MOSS, SharePoint, SharePoint Designer, Composite Applications, Architecture

How does IT Move?

2009-05-19T15:42:08.613

I've worked for organizations where IT moves too fast (and thus wastes money and alienates customers) and others where IT moves too slow (and thus the customers go around IT as much as possible). I've also worked in places where IT does both, often in the same day.

This week, I have the pleasure of sitting in all-day meetings related to a series of IT infrastructure projects we are pursuing. The folks in charge of coordinating this effort brought in a vendor to lead a brief engagement designed to help IT project teams and key business stakeholders better understand how to proceed with these key projects. This is a noble goal, and it's one I support. However, I fear that the engagement was put together too quickly and with almost no deliberation. It's just my opinion, of course, and I'm sure that this engagement will have some value. I, for one, want to make sure that we obtain that value even though the process has been a bit hasty. But will it have equal value to the dollar amount on the contract? That I don't know.

To be fair, I'm certain that we're moving quickly in this effort because we've been far too slow with similar efforts in the past. But, it seems as though the pendulum has swung the other direction. So here is the underlying question: How does IT get things done, without moving too fast or too slow? Here are a couple of my thoughts off the top of my head:

1) Empower people in the right places - IT doesn't need to poke it's nose into all areas of the business just because something smells like technology. The question is, what information technologies do we need to be involved in?

2) Respect the Business and Keep them Informed - IT managers like to talk about getting users in the room, then they go and demand they be present without respect for the ever-crushing workload which they have to deal with. If you need to move fast, and you need your customer, it's your responsibility to move mountains for them, not ask that they do so for you.

3) Remember who you are working for - An extension to number 2. Sometimes is looks like IT is the tail wagging the organizational dog, as if our business units exist to use our technologies. If IT feels the need to get things done fast, then I would imagine that there is a good business reason for doing so (there had better be). If that's the case, its our responsibility to help the business understand how moving fast is our best bet for meeting that need. When we help the business understand that, they get in our corner and help us move as a partner, not someone we feel the need to drag along.

What else am I missing here? Quite a bit, I'm sure, so additional thoughts would be appreciated.

Technorati Tags: Business Architecture, EA, Enterprise Architecture

Amazon S3: Now with SLA!

2009-05-19T15:42:08.413

Saw this post from Brady Forest on O'Reilly Radar, which points to the official announcement on the AWS blog. This may not mean as much to many of you who have been using S3 for a while now, but it's big news for a guy like me because I know better than to bring technologies like S3, EC2 and Mechanical Turk into any serious internal conversation unless I can say "yes" to that SLA question. Looks like AWS is getting ready for prime time. And why not? Most of us have been expecting this for a while now.

I will echo Arthur's request for more to the SLA, specifically for stats on uptime and availability. I think that all services should provide information like this to be as clear as possible in letting you know what you are getting by consuming said service (and our internal guidelines say as much), but this kind of information is especially vital with services in the cloud. I'm confident that they'll get there, but in the meantime, I'll echo that feature request.

On another note, why the heck is O'Reilly charging $149 for a glorified whitepaper on developing applications for Facebook? I use Facebook. I like Facebook. I think there is something to be said about developing applications for it... in certain situations. But could we just take a moment to breathe here before they hype train carries us all away?

Technorati Tags: Amazon, S3, EC2, Mechanical Turk, O'Reilly, Facebook

Links for 2007-10-06

2009-05-19T15:42:08.013

SOA: Sometimes it IS about the technology - Both Nick's post and Andrew McAfee's original are worth a read and right on. I think the pearl of wisdom is for all of us to stop advocating one extreme or the other ("x is about technology" vs "x is not") all the time and start using wisdom, common sense and a willingness to either talk about technology (when the situation calls for it, as Nick describes when one must know which "... goals are realistically achievable given current technology trends") or leave technology out of the discussion (when the situation calls for us to convey to the business that we truly get their business need and aren't simply looking for a way to implement the cool new technology).
Why Microsoft Should Not Support SCA - Bottom line as I read this: Microsoft doesn't benefit and neither does anyone else. It makes sense, but David certainly makes SCA seem like less of a "big deal" standard than others want us to believe. Not sure what I think yet, but I would highly recommend David's Introducing SCA article. It's a good read and provides a good overview of some big technology movements outside of the Microsoft world.
Green Datacenter Initiative - The idea of "Green IT" is becoming a bigger and bigger deal as more organizations realize that Global Warming is not a joke (it never was) and that the measure corporate ethics and responsibility will increasingly include the impact of their IT organization on the environment. As Simon says, the measurement technology isn't there yet, but why not start grassroots with your own PC. Downloaded the LocalCooling app Simon links to and get an idea of how little things we all do as individuals does have an impact.

Technorati Tags: SOA, SCA, Microsoft, Green IT, LocalCooling

Links for 2007-10-04

2009-05-19T15:42:07.7

Releasing the Source Code for the .NET Framework Libraries - Kudos Microsoft. No question that this is a good move.
TED 2007 - The seemingly impossible is possible (Video) - Hans Roslings uses some of the best information visualization I have ever seen (Google must agree, because they bought his Gapminder tool) to deliver a great 20 minute presentation about how our cut and dry segmentation of the world into developed and developing countries is wrong and that we have the means and ability to eliminate poverty in our lifetimes. It's well worth 20 minutes.
Is Twitter Useless, Asinine, or The Crocs of The Web? I love the comparison of Twitter to Crocs and think it's true: There are those that find Twitter pointless (my wife) and those that can't understand why people can't see the simple elegance of power of it (myself). But more than the ability for me to know where my friends are going for dinner, Twitter is a paradigm for multi-channel information sharing and that can be quite powerful for organizations as well as individuals.
Learning from Bill Gates & Steve Jobs - Steve Jobs' amazing presentation skills isn't news to anyone, but I like this post largely because of the side-by-side depiction of a Bill Gates slide deck and a Steve Jobs slide deck. It makes a strong point...

Technorati Tags: .NET, ScottGu, TED, Gapminder, Google Gears, Twitter, Presentation Zen, Bill Gates, Steve Jobs

Links for 2007-10-03

2009-05-19T15:42:07.193

Office Live Workspace revealed: a free 250MB "SharePoint Lite" for everyone - This isn't the Google killer since it's not an "online" version of the classic office applications. What it is is the slow-moving-and-customer-ignorant-IT-organization killer, which is a great thing as far as I'm concerned.
Sharepoint is not a good development platform / SharePoint is a good development platform for applications / SharePoint is an Awesome Dev App Platform - One of our SA's said early on in his experience with MOSS 2007 application development that "MOSS takes the rapid out of Rapid Application Development," which I think is true in the OOB development experience. Since then, however, we have been able to experiment with varying ways to develop apps in MOSS and have started to see areas where we can create value and assist in speed by abstracting out some of the complexity. That being said, Visual Studio needs to catch up and help make that development experience richer. As Andrew Connell said, that's a knock on tooling and the development environment, not the platform itself.
MOSS Faceted Search (CodePlex) - If you're using or plan to use MOSS and you want your users to get the most value out of Search, I would recommend taking a serious look at faceted search.

All MOSS Links today... some days are just like that I suppose. :)

Technorati Tags: MOSS 2007, Search, Architecture, ECM, Portal, .NET, SharePoint

Composite Applications Visualized

2009-05-19T15:42:07.007

I published v1 of my Composite Applications Framework document last Thursday and am pretty pleased with the result. As with all things, it will evolve and improve over time, but I think it was a decent first salvo. I am indebted to Mike Walker and Todd Biske for their input. My favorite part about blogging is being able to have access to and input from such brilliant people.

As I worked back through the draft of the document, I realized that some key visuals were missing in relation to the various composition terms I wrote about in my last post, as well as a view of the CAF architecture. I don't have time to go into these in detail, but I'll post them here. Feel free to refer back to my previous two posts for more context. As always, I'd love any feedback that anyone is willing to throw my way.

This first image was designed to depict the relationship between some of the composition terms I used in my last post.

The second image expands on the first, but includes example tiers, containers and assets. Many of these examples are specific to the Microsoft universe, specifically MOSS 2007, while others are generic.

The final image depicts many of the technologies that I believe play a key role in a CAF. This is not meant to be an end-all-be-all list, or even the best depiction available. Just food for thought.

So there you have it.

On a personal note, I'm off for a two week computer-less vacation this afternoon, so the blog will be silent during that time. I'll be back in the swing of things on September 22nd and hopefully I won't be so buried in the blogs I read that I'll have a moment to write a thing or two that weekend.

Links for 2007-09-06

2009-05-19T15:42:06.813

The Importance of Mentor - Joe Says: "I say if you want to do something with your life and are willing to make a life-changing and risky change in your life to pursue that goal, then stop being such a chicken and go for it." Agreed. Great post Joe.
SOA and the ROI - If you sell SOA without ties to MDM, Portals or Process Improvement initiatives, you're just selling a technology with the ability for reuse, but no framework to foster reuse.
Periodic Table of Visualization Methods - Just about every conceivable way to visualize information is on this table, with examples. A great resource to keep around for a visual learner such as I.

Technorati Tags: Mentor, SOA, Information Visualization

Composition: Assembling Assets into Applications

2009-05-19T15:42:06.357

In my last post, I posted an except from a strategy document I am working on around the creation of a Composite Application Framework (CAF). The section I posted dealt specifically with the need for application composition within IT. Soon after I posted, Mike Walker, an Architect with Microsoft's Architecture Strategy team, posted a response with some thoughts of his own. As I said in the comment section of that post, I think Mike's additions were right on and plan to incorporate some of his thoughts and comments as I revise that section in the final publication.

In the first section of his post, Mike took a moment to define the term "composite applications" using definitions from Gartner, BEA, IBM and pointed to Chris Keyser's Architecture Journal paper from January, "Composite Applications: The New Paradigm." The last was a key piece of my research and I highly recommend reading it as it discusses composition from a broader view than just SOA, which is contrary to the focus of most first generation thinking on composite applications.

Mike's definition aligns with what I included in the second section of my research paper, which I am posting here. This section shifts the focus from justifying the need to understanding all of the terms in the CA universe as we've defined it. Thus, it includes a bit more than just defining Composite Applications. Mike, I'd be interested in further thoughts or feedback you might have on this section. Same goes for anyone who wants to jump in. Here's section two:

Composition: Assembling Assets into Applications

In order to create a Composite Applications Framework (CAF), one must first understand the vocabulary of composition and composite applications. This section introduces several terms and concepts important to the creation of a CAF. They are:

1. Composition

2. Composite Assets

3. Composite Applications

4. Composition Tiers, Composite Types and Containers

5. Composers

Composition

According to Wiktionary, composition is the combining of different parts to make a whole. In the context of technology, composition is the combining of technology assets to create an application or solution which provides value to the business. According to Keyser, the term itself is a "... shift in computing from brittle, monolithic, developer-centric applications solving one particular problem, to agile, contextual, user-driven applications to support a particular business process." (2006, p. 5) In addition to agile and user-driven applications, composition also "... includes personalization and customization abilities, so that users can easily and quickly modify specific functionality in the solution." (Banerjee, What are Composite Applications?, 2006) In essence, composition is the assembly of assets into applications which can be created and/ or modified quickly and are user-driven in nature. Thus, enabling composition of assets into applications is the key and ultimate goal of a CAF.

Composite Assets

Within the realm of Composite Applications, a composite asset is a discrete object with standalone value and functionality which can be combined with other objects to create an application of greater value than the sum of the individual objects. Typically, this combination is in support of a business process or set of user goals. Within a CAF, the following objects can be considered assets for composition (Adapted from Banerjee, Building Office Business Applications, 2006 and What are Composite Applications?, 2006):

Documents	Dashboards
Business Activities	Portal Sites
Business Rules	Portal/ Web Pages
Schemas	Data Connections
Metrics	Authorizations
Web Parts	Reports
Web Services	UI Screens

It should be obvious from this list that the creation of composite applications goes far beyond the assembly of WebParts on a screen to create a single interface. In fact, composite applications span all of these types and all of the traditional application tiers. To create a successful CAF, IT should create a CAF that allows most, if not all, of the assets listed above to be used in the creation of Composite applications.

Composite Applications

The term "composite applications" evokes many different meanings in the current landscape of information technology. A few examples are:

Applications created via the assembly of SOA services;
The Business user's equivalent of Web 2.0 "mashups;" (Keyser, 2006)
Another form of integration and application development; (Frye, 2005)

While these are all valid interpretations, they are also nearly all tied to first generation ideas around the meaning and intent of composite applications. Core to that idea was that the only useful assets for composition were either Web Services or entire User Interfaces. Thus, much of the current writing and thinking around composite applications centers on either the composition of fine-grained SOA services into "right-sized" business services, which are then wrapped in a UI and delivered to the user, or the creation of Web Parts which are dragged onto a portal screen, skinned and placed wherever the user desires.

While we still hold the first generation thinking around composite applications to be true, we believe that composition is more than simple service composition or the creation of WebParts. Furthermore, composition is a reality for all of the assets listed above and also at every tier of an application and for each major type of composite application. Thus, a candidate definition of a composite application is "... a collection of software assets that have been assembled to provide a business capability. These assets are artifacts that can be deployed independently, enable composition, and leverage specific platform capabilities." (Banerjee, What are Composite Applications?, 2006, p. 12)

Composition Tiers, Composite Types and Containers

Because a CAF should support more than service and WebPart composition, it is important to understand the tiers of composite applications, types of composite applications and the containers available at each tier. An understanding of each enables solution teams to determine the appropriate placement for a composite application.

Composition Tiers are application layers that provide services to composite applications.

Composite Types are categories of composite applications which map to each composition tier.

Containers are shells which can host any or all of the assets that make up a composite application.

Presentation Tier - UI Composites

The primary function of the presentation tier is to present business information to knowledge workers and actions to perform on said information. Composition at this tier is called composition "at the glass." (Sholler, 2006) UI Composition is one of the most common forms of composition and is often assumed to be the only tier at which composition takes place because of its broad use and visibility. However, this misconception often causes organizations to attempt to create a CAF simply by creating a "whole cloth" UI through which all applications must be surfaced. The result is a single interface (instead of a unified User Experience) which ends up constraining business users and diminishes the value of a CAF.

Instead of a one-size fits all CAF with exclusive UI composition, organizations maximize the value of a CAF by leveraging composition at the level where it is the most appropriate option for a given composite application. In the case of UI composites, these are most appropriate when the resulting composite application should describe the sequence of interactions the end user will need to follow in order to use the application. (Sholler, 2006) In addition to sequenced composites, UI composites are also appropriate for "informal and unintended compositions." (Keyser, 2006, p. 3) In both cases, an Enterprise Portal environment is the ideal host for these types of composite applications.

Application Tier - Service/ Integration Composites

Composition at the application tier typically involves the creation of new services from existing services to enable a business process or set of user goals. Composites created from existing services are new services themselves which may also be candidates for composition. These services are usually managed by an integration/ orchestration engine such as Microsoft BizTalk Server. Similar to Presentation Tier composites, these composites can have UI elements and trigger user interactions, but the key difference is that the actual composition takes place at the service level. These types of composites are most appropriate when the composition describes automated business activities or a subset of an automated business process. (Sholler, 2006)

Data Tier - Data/ Information Composites

Composition at the Data Tier consists of creating services for managing the content and relationships of a business entity. These services are designed to be the building blocks for the creation of other services and are typically not surfaced to a UI. Data Tier composites are most appropriate for consolidating views of shared reference information and are usually the foundation for SOA. Key to the success of Data Tier composition is the establishment of Enterprise Information Management (EIM) processes and practices in an organization. EIM practices, especially those targeted at Master Data Management (MDM) go a long way toward addressing many of the entity aggregation and information integration issues which typically plague SOA and CAF implementations.

Productivity Tier - Ad-hoc Composites

Productivity Tier composites are composites used to manage the "rhythm of the business:" those ad-hoc interactions, collaborations and processes which all knowledge workers rely on to accomplish their goals. While discussions around SOA, Enterprise Service Buses (ESBs) and open standards like WS-* and Service Component Architecture (SCA) are valuable, they are all focused on managing and exposing structured business logic. However, the greatest business value for composition can be found at the Productivity tier. (Keyser, 2006) Furthermore, the very idea of composition begs for a framework which supports ad-hoc processes. According to Banerjee, "By their very nature, composite applications presume that composition of solutions can occur after assets have been built and deployed-and so need to explicitly account for people-to-people interactions among information workers that are essential to complete any business process. Usually these interactions are not captured by structured processes or traditional business applications." (Banerjee, Building Office Business Applications, 2006, pp. 12, 13) These types of composites are most appropriate when processes either cannot or need not be defined, or when the business requires a solution that works "in between the boxes" of defined processes.

Each of these tiers and types provides a set of containers within which assets can be hosted. Examples of containers at each tier are:

Presentation - Outlook, Excel, InfoPath, WSS WebParts
Application - Web Services, LOB Systems
Data - Analysis Services, Data Warehouse, EIM services
Productivity - MOSS Document Libraries, Excel Services, Workflows, Business Data Catalog

Composers

One of the key questions related to the creation of composite applications and a CAF is "Who composes?" That is to say, "What roles would be involved in the assembly of composite applications?" Organizations have several options when determining the primary composers of composite applications and the choice has implications on the design of both a CAF and the experience in creating composite applications. Some likely composers of composite applications are:

Business Service Developers

These are IT developers focused on providing value-added common business services to all customer solutions teams. Their technical depth is high and a CAF targeted at these users would be similar to what is provided by SOA today.

Customer Solution Developers

These are IT developers focused on creating customer-centric solutions by leveraging software infrastructure. Their technical depth is moderate to high and a CAF targeted at these users would need to abstract away service creation and assembly.

Business Analysts

These are customer consultants focused on helping customers determine which business needs are best met with technology. Their technical depth is moderate and a CAF targeted at these users would draw many features from current leading BPM platforms.

End Users

These are the users of the solutions created by customer solutions teams. Their technical depth is low and a CAF targeted at these users would need to abstract away nearly all of the technical aspects of application creation and should provide very intuitive context- and metadata-driven methods for application assembly and customization.

For many organizations, it would be advisable for a first generation CAF target Customer Solution Developers as the primary composers of applications, with some configuration, customization and personalization provided to business analysts and end users. Once the CAF is in place, the framework should evolve over the long term to push composition out to Business Analysts and eventually to end users.

References

Banerjee, A. (2006). Building Office Business Applications. The Architecture Journal, (10) 12-19.

Banerjee, A. (2006, December). What are Composite Applications? Retrieved August 20, 2007, from MSDN Architecture Center: http://msdn2.microsoft.com/en-us/architecture/bb220803.aspx

Banerjee, A., Moinuddin, M., & Walker, M. J. (2006). Office Business Applications: Building Composite Applications Using the Microsoft Platform. Redmond: Microsoft.

Frye, C. (2005, July 20). The role of composite applications in an SOA. Retrieved August 20, 2007, from SearchWebServices.com: http://searchwebservices.techtarget.com/qna/0,289202,sid26_gci1109080,00.html

Keyser, C. (2006). Composite Applications - The New Paradigm. The Architecture Journal , (10) 2-5.

Phifer, G. e. (2007, July 13). Hype Cycle for Web and User Interaction Technologies, 2007. Retrieved August 20, 2007, from Gartner

Sholler, D. (2006, December 12). Three Approaches to Building Composite Applications. Retrieved August 13, 2007, from Gartner

Technorati Tags: Composite Applications, OBAs, Composition, SOA, Architecture, Enterprise Architecture

The Need for Application Composition

2009-05-19T15:42:05.91

If you've been following me on twitter, you'd probably be able to venture a guess as to why I've been mostly silent for the last two weeks: I've been frantically working away at an internal strategy and vision for a Composite Application Framework (CAF). I finished a draft Wednesday and am going through a self-imposed peer review process before publishing next week. In addition to internal peer review, I wanted to start engaging some peers in the blogging world for their opinions on the ins and outs of both the need for and the creation of a CAF in an enterprise. Part of that includes, of course, some discussion around the meaning of "Composite Applications" and CAF, which has several meanings: from being synonymous with SOA (only the beginning IMO) to Web 2.0 in the Enterprise (or Enterprise 2.0 if you like, which I do not). However, before I get into the weeds of terminology, I wanted to share an excerpt from the document that establishes the need for composition period, be it via SOA or Web/Enterprise 2.0. I've taken out anything specific to my company, but the rest is true to the first draft of the doc. I would love to have feedback from Mike Walker, James McGovern, Todd Biske, Nick Malick, Mike Kavis and anyone else who wants to weigh in. Going forward, I plan to post some additional sections from the doc for your consumption, review and feedback of any kind. I hope it at least generates some good discussion. So without further ado...

The Need for Composition

To understand the value that a CAF provides for an organization, it is important to first understand environmental trends which are driving IT organizations to reevaluate their current delivery models and to pursue composition strategies. In particular, I believe that there are five factors which illustrate the need for an application composition strategy. These factors are:

The Cost of Building Applications
The Problem with Processes
The "Consumerization of IT"
The Need for Agility
The Desire for a Single User Experience

The Cost of Building Applications

A current reality many organizations face is that IT costs are increasing while businesses are asking for more controls on IT spending. While the high cost of IT solutions isn't new, more and more organizations are pointing to the cost of integration as a major culprit behind IT cost overruns. According to Ebstrategy.com, "The cost of integration is rapidly becoming a significant barrier to the deployment of new business applications. EBS estimated that in large corporations, approximately 40% of the cost of new applications is spent linking disparate business processes and applications rather than delivering new business functions." (E-Business Strategies, Inc.) Furthermore, Dr. Jean-Jaques Dubray of Attachmate argues that increasing integration costs are a sign that IT is nearing or has crossed the point of "negative ROI," beyond which the costs, risks and complexity of integration make it nearly impossible for the organization to realize any ROI from its efforts. (2005, p. 9) The figure above illustrates this theory of increased cost and decreased value as the number of systems in an organization increases.

As a result of this increased cost, Dubray concludes that "...companies are limited in their ability to improve existing business units operations or expand their businesses because all changes in a company's operation translate into modifying or creating new [Line of Business (LOB)] systems." (2005, p. 9) The increased cost of applications due to integration cost and the resulting limitation in IT's ability to deliver value to the organization contributes a great deal to the perception that IT is too expensive and slow to respond to the needs of the business.

In response to increased cost and this perception, Dubray argues that IT "...can no longer afford to build assets that cannot be reused in future contexts." (2005, p. 9) Instead, IT must view everything it creates for the business as a collection of discrete and reusable assets. In addition, IT must create a framework that enables both the creation of reusable assets and the reuse of those assets in the creation of solutions.

The Problem with Processes

The systems that IT creates are typically designed to manage discrete steps in a structured process. An example is web content creation, which typically involves story creation, moderation, publishing and retirement. Historically, IT systems have focused on automating approval, publishing and retirement and have been successful at creating value along these steps. However, the largest step in this process (in terms of elapsed time) is usually the first: story creation. It is also likely the most collaborative and would likely consist of several "ad-hoc" process steps where the author collaborates with other individuals to check facts, obtain more information and even elicit feedback on the document in progress. But the system in question assumes that a completed draft is step 1 in the process. The result is that most applications "...do not enable rich collaboration across functional boundaries. This usually leads information workers to use personal productivity tools to perform the complex interactions required to conduct business. However, this in turn leads to a loss in productivity, as users are forced to cross from one set of tools to another, often manually moving the data through means such as cut-and-paste." (Banerjee, 2006, p. 12)

IT cannot focus merely on process automation to create value for the business when the reality is that most processes involve "...much more work between elements than is represented in the initial structured process. This work is often collaborative in nature. Innovation frequently takes place outside structured processes in the collaboration interactions, where imagination predominates, where the creativity of information workers is truly tapped, and where the critical business differentiation occurs." (Keyser, 2006, p. 3) Instead, IT should seek to create applications that enable and enhance the productivity of information workers along both structured and ad-hoc processes, as illustrated in the Figure above (Banerjee, What are Composite Applications?, 2006).

The "Consumerization of IT"

The "Consumerization of IT" is a term coined by Gartner to describe the effect of popular technology outside of the enterprise on the expectations and needs of knowledge workers within the enterprise. Gartner argues that knowledge workers are learning new and creative ways to use the web for productivity and collaboration and that they will expect to have these methods and tools available to them in the workplace. According to Keyser, "Based on working with Web 2.0, users will increasingly expect to exert more control over their work experiences and to participate in them. They will expect business applications to adjust to the way they work, rather than accept a suboptimal experience." (Keyser, 2006, p. 2) An example of this shift has been illustrated by a recent poll conducted on Facebook.com by the Gilbane Group (Gilbane, 2007).

In this poll, participants were asked to select from a list of collaboration technologies which they plan to use in their jobs the most over the next two years. The respondents were then broken up into two groups (18-24 year olds and 25-34 year olds) and a visualization of the results can be seen in the figure above. While it's a bit of a surprise that younger knowledge workers will expect to use social-networking sites and SMS text messaging as a part of their jobs and not merely for play, a key piece of information in this unofficial poll is that many younger workers would prefer not to use email as a collaboration tool.

The implication, in my opinion, is that IT cannot paint users into a corner by offering one prescribed way in which to accomplish a task or achieve a goal when another tool or method might enable users to be far more productive. In reality, the "Consumerization of IT" means that the use of technology and the tools at an information worker's disposal are becoming a large part of job satisfaction outside the walls of IT. IT organizations should recognize this trend and seek to provide solutions with the flexibility to meet the technology demands of information workers.

The Need for Agility

Many organizations frequently express a desire to obtain the flexibility to quickly respond to meet new opportunities and demands as a "high priority" which they expect IT to enable. (Keyser, 2006, p. 2) As an organization grows, there is an increasing need for IT to provide the organization with:

A platform for rapid decision-making;
Tools to help the business sense and respond to changing market conditions;
The ability to align business needs with current and future IT assets.

To support these business needs, IT organizations should be able to provide applications which are:

Quick and easy to deploy;
Easy to modify, customize and extend;
Aligned with the current and future needs of the business.

All of these factors illustrate the need for IT organizations to provide infrastructure and solutions which enable an organization to respond quickly and easily to change.

The Desire for a Single User Experience

As organizations grow their products and services, they typically outgrow the LOB systems they purchased or built to manage their earlier products and services. Those legacy systems are typically run to support the existing business, while new systems are created in new interfaces and bolted into the organization to run new businesses. The result for most users, who typically work with similar business processes across all products and services, is a small to large number of disparate systems within which they perform their daily work. Over time, the business begins to call for integration and a unified User Experience for knowledge workers in an organizations. Organizations who have been successful at implementing SOA usually lay the groundwork for meeting this need, but the path to a single User Experience includes a framework which brings data, processes and interfaces into a shared and consistent experience for knowledge workers.

It is important to note here that a single User Experience is not a single user interface or a single system. Rather, a single User Experience is offered by a platform and a controlled number of user interfaces which provide familiar interactions to knowledge workers regardless of the medium, be it Office client, web application, mobile device or smart client.

References

Banerjee, A. (2006). Building Office Business Applications. The Architecture Journal, (10) 12-19.

Banerjee, A. (2006, December). What are Composite Applications? Retrieved August 20, 2007, from MSDN Architecture Center: http://msdn2.microsoft.com/en-us/architecture/bb220803.aspx

Banerjee, A., Moinuddin, M., & Walker, M. J. (2006). Office Business Applications: Building Composite Applications Using the Microsoft Platform. Redmond: Microsoft.

Dubray, D. J.-J. (2005, May). Composite Applications: Value Proposition and Architecture. Retrieved August 20, 2007, from ebMPL.org: http://www.ebpml.org/capp.ppt

E-Business Strategies, Inc. (n.d.). Composite Applications - Frequently Asked Questions. Retrieved August 20, 2007, from EBS Web Site: http://www.ebstrategy.com/selfservice/composite/composite_apps_faq.htm

Gilbane, F. (2007, June 20). More Data on Facebook users and Enterprise 2.0. Retrieved August 20, 2007, from Gilbane Group Blog: http://gilbane.com/blog/2007/06/more_data_on_facebook_users_an.html

Keyser, C. (2006). Composite Applications - The New Paradigm. The Architecture Journal , (10) 2-5.

Platt, M. (2007). Web 2.0 in the Enterprise. The Architecture Journal , (12) 2-6.

Technorati Tags: Enterprise Architecture, Composite Applications, SOA, User Experience

Links for 2007-08-15

2009-05-19T15:42:05.68

SSIS Team Development Experiences - Another example of database developers being left out in the cold when it comes to first-class development tools and practices. It's getting better, but we're not there yet...
Adaptive Path UXWeek - Simon Guest is at UXWeek and will be blogging about the experience. I hope that the number of EAs only increases in coming years and hope to attend myself in the future.
Go old school with a notebook - I'm a tried and true notebook guy. There is no and never will be an adequate replacement for pen and paper for me...
User experience and the analysts - A nice piece of research done by Rosenfeld Media on major Analysts use of certain UX-related terms. The Gartner ones weren't surprising to me as a Gartner client (though I would imagine that they would argue that the "Consumerization of IT" term is a UX term, thus should be on the list), but it was interesting to see some side-by-side comparisons. More research along these lines would help an organization like mine have some good insight into which firm, if any, should get our money.
DSLs bringing the end of single language development? I hope so... especially if one is more open with the terms "language" and "development."
Are You a Synthesizer? Enterprise Architects have to be... I sure hope I am. If I'm not, I'd like to become a professional fly fisherman...
Enterprise 2.0 is about building a collaboration platform that is better than e-mail - The reality, as Jason states himself in this article, is that Enterprise collaboration (I won't use that term in the title) is less about replacing email and more about repositioning email to be used correctly (messaging) and bringing other tools into the enterprise which are better suited for collaboration (like Parlano). (via Joe Lewis)

Technorati Tags: SSIS, Adaptive Path, UXWeek, EA, Lifehacker, Moleskine, UX, Gartner

Links for 2007-08-06

2009-05-19T15:42:05.38

Microsoft: My way or the highway with SOA? Though Microsoft can certainly afford to do "SOA their way" and though such approaches have certainly worked in the past, I wonder if this one might actually hurt them is the long run. As Joe says, "What Microsoft appears to be doing... goes completely against what SOA is supposed to be all about, which is the ability to deploy and run what you need based on what you need, unencumbered by the limitations of vendors' systems." Wouldn't it be ironic if Microsoft's way of forcing organizations to "do SOA" causes organizations to turn to SOA itself as a way to minimize their dependencies on Microsoft systems?
Project Zero: IBM enables REST-based development - Not surprising to see IBM adding support for REST, especially since Microsoft is doing the same by adding a Web Programming model to its WCF upgrades in the .NET 3.5 Framework. In many ways, this simply underscores David Chappell's assertion that the REST versus WS-* debate is over. While we may still have a place in our hearts for one over the other, the major vendors seem to be saying "why not both?"
Binding SOA to BPM instead of BPM to SOA - Not sure I understand the assertion that we should attach SOA to the swimlane diagram and not BPMN Nick. Pools and Lanes are used heavily in BPMN, so what is it about BPMN that you have an issue with? If it's the BPEL/automation side of BPMN, then I agree, but I think that BPMN can be very useful to organizations without that side, especially since what you get is a standard Process modeling language where none exists today.
Why Sales isn't process driven - According to Steve Jones, the "mechanism for the implementation and measurement of a service" (process) isn't always the same thing as the drivers for and value of the service (goals). Meaning that our services ought to pay attention to user goals first and the underlying process second. It's a UCD/UX perspective for SOA...
PowerPoint: Boon or Bane? I tend to fall into the camp of PowerPoint is a misused tool, not a bad tool in and of itself, though its conventions in the form of automatic title and bullet regions do encourage bad behavior.
Stuff - I read recently that it took the self-storage industry 25 years to build the first billion square feet of storage space and only 8 years for the second billion. Yet our houses have grown by 80% and we still face a storage crisis. Stuff is best gotten rid of...

Technorati Tags: SOA, Microsoft, Project Zero, IBM, REST, BPM, BPMN, UCD, UX, PowerPoint

Links for 2007-08-05

2009-05-19T15:42:05.19

Enterprise Architecture, REST and SOA all sit down at a bar? - More on REST, SOA and EA and EA's responsibility to be relevant to project teams.
Do Enterprise Architects ask Stupid Questions? - There are no stupid questions, only questions that self-righteous people think are stupid.
Build versus Buy versus Opensource - Good advice if you can get Opensource in the door. Of course, vendors charging a premium to solve common problems already solved should be reason enough to adopt opensource...
Loc.alize.us - A Google Maps and Flickr mashup that brings photos of different lands to you. I'm planning a trip to Italy right now and it's nice to be able to get more than just the top-down view that Google Earth and Maps provide. Google Earth has functionality similar to this, though I like the UI here better.
What SOA needs to learn from Ruby On Rails - Though I'm not sure what "Canned SOA" would look like, I agree with the argument that SOA needs some measure of default convention which can be leveraged.
The Developer Theory of the Third Place - My third place is usually one of several coffee houses or restaurants with free WiFi close to my work or home. BTW, If you're ever in Colorado Springs Scott, we'd love to have you drop by and share some of your expertise.
Free Code - Getting IT out of the Applications business - IT takes EIM and the Business Event Ontology and gives the business (Biz Process Devs specifically) the ability to write "free code." While it sounds a little counter-intuitive, it certainly has some promise.

Technorati Tags: Enterprise Architecture, EA, REST, SOA, Opensource, Ruby on Rails, BPM

EA Collaboration Tools: RACI Charts.

2009-05-19T15:42:04.997

I've spoken a bit recently about Enterprise Architecture as a collaborative tool, rather than a command and control structure. Talking about collaboration is good, but it takes more than a desire to collaborate to move EA in that direction. In reality, collaboration is an intentional effort, not just something you do by getting a group of people together and talking about architecture. While that's a key first step, and one you can do right now to improve your current landscape, collaboration is a culture which must be encouraged and fostered and which requires stronger leadership than any command and control structure ever does. But I don't want to talk about the soft skills of leadership today. Instead, I'd rather talk in this and another post or two about tools that make EA Collaboration a richer and deeper experience. By tools, I don't mean modeling tools, repositories or frameworks. Those things have their place, but EA is also about people, and the tools of which I speak are tools that help people work together. These are common, simple tools that don't cost an EA team much, but which can add a good bit of value to your efforts.

The first is a communication tool called a RACI Chart. A RACI chart is a simple device used to describe the roles and responsibilities of a group of people in completing certain tasks or deliverables. An example of a RACI chart from Wikipedia is depicted on the left and illustrates tasks or deliverables as rows (what is being worked on) and roles as columns (who is working on it). At the intersection of each task and role is a letter (R, A, C or I) to represent a role's level of involvement in a task. Here is the meaning of each letter:

Responsible - The person who does the work. (There can be multiple)
Accountable - The person accountable for the completion of a task, or the "single wringable neck." (There can only be one)
Consulted - A person or people with input into the task. Their expertise is needed.
Informed - A person or people who "need to know" the outcome, but who need not be consulted during the process.

So why is this valuable to EA? For me, the reason is because it removes assumptions and brings clarity to collaboration. RACI charts enable a group to go into a process or task with a clear understanding of everyone's role. Differences of opinion over the level of involvement are resolved up front, which makes it that much easier for a group to move forward on the "same sheet of music" so to speak. Without clarity, you usually create conflict around contribution (bad), rather than conflict around content (good).

Here's an example of a RACI chart that lists some common Architecture deliverables (both Enterprise- and Solution-level):

I won't go to deep into the content here because the deliverables and roles don't apply to every organization. For that matter, neither do the structural and cultural issues that play into "correctness" of this particular chart. The key is to recognize that the chart clearly identifies Rs, an A, Cs and Is for each deliverable listed as they relate to various roles in the organization. On the occasions where I have leveraged this method in the past, I was encouraged by the clarity it brought to the teams with which I was working. On one occasion, I was told that this model helped one individual put his finger on some past frustrations he had around certain deliverables and also understand with clarity how he "fit" into these cross-functional decisions.

Of course, these charts are no substitute for open and honest discussion and they should never be used as a way to manipulate people. They are intended to bring clarity and should be used only to obtain it. Once you've got it, it's time to move on to the task art hand, which you'll do with a lot more clarity than you would have otherwise.

Technorati Tags: RACI, Architecture, Enterprise Architecture, Collaboration

Links for 2007-08-03

2009-05-19T15:42:04.84

Never Email Anyone Over 30 - I've seen many enterprises that think that Email + IM = collaboration needs met and I find it pleasantly surprising to see that IM as a collaboration tool is diminishing in the eyes of the younger generation of workers in favor of things like SMS, Wikis and Blogs (Twitter is probably just about in its own category). What that means however is that the enterprises who are just now getting IM in the Enterprise are still behind the curve... so what's your strategy for embracing the next generation of collaboration tools? Does an Enterprise vendor have to offer it before we'll buy it?
Practical Enterprise Architecture - Some good tips on creating valuable Enterprise Architecture.
What is Enterprise 2.0 - As much as I don't like the phrase, or "concept versioning" in any form, I like what the idea represents in terms of driving information access, interconnected applications and devices and collaborative and open work.
SubSonic - This looks to be a very nice ASP.NET scaffolding framework that parallels much of the project start-up scripts that makes Ruby on Rails such a nice environment to work in. (via Ken Scott)
Should people adapt to computers? - Agreed Scott. I think that people have adapted enough... it's time to set them free, and I don't mean by turning their coffee table into a computer either.
Enterprise Architects versus Business Architects - While I certainly don't think that the role of EA is to create services within an Enterprise SOA, I do think that EA has a responsibility in handing valuable business process knowledge to an SOA team that then knows which services are needed. Otherwise, services end up being created to wrap whatever database entities a given project needs next. In any case, the key is that EA has a responsibility to be relevant to SOA efforts, not the other way around.
Enterprise Architecture is like Herding Cats - Don't know what I could possibly add here...
Is Serendipity the Heart of the WS-*/REST Debate? Serendipity is probably a large part of the discussion, but I think a key to Nick Gall's General Principle of Serendipity ("Just as generality of knowledge is the key to serendipitous discovery, generality of purpose is the key to serendipitous (re)use.") is that one can rarely (even in an enterprise) plan for explicit reuse of a service. As such, you plan for serendipity.

Technorati Tags: Collaboration, Twitter, Enterprise Architecture, EA, Architecture, Business Architecture, SOA, REST

Links for 2007-08-02

2009-05-19T15:42:04.66

Daily Lit - Get daily installments of public domain books delivered via email or RSS. I've started with Walden and should be done in 124 days... assuming I read these installments daily, of course.
The Manifesto of the Futurist Programmers - There's nothing like a thousand words of propaganda to get your blood boiling over vague ideas and foggy platitudes (via CodingHorror).
Does Visual Studio Rot the Mind? - A great article from Charles Petzold on the ways that Visual Studio might hinder us as programmers. From a User Experience perspective, I think that the broader critique here is that systems which define our way of working instead of conforming to our way of working probably cost us more than we realize.
Ha Ha, you must be joking - This is what happens when governance isn't seen as an enabler and a way to support a person's natural action. Instead, this is governance from an "us vs. them" perspective.
A First look at IronRuby - Microsoft's venture into Ruby looks pretty good so far, and the plan to move IronRuby into Rubyforge is worthy of applause. Tactically, I am still trying to wrap my head around this Dynamic Language Runtime (DLR) idea and it's place on top of the .NET Common Language Runtime (CLR). Is it just a deferred compilation model? If so, is that really dynamic? Maybe I am missing the point, but I am having a hard time finding a good summary of the inner workings of the DLR. If anyone has anything, please send it my way.
All models are wrong, some models are useful - A true statement, and the extension of this maxim to include communities is correct as well. When we worry less about "correctness" of the community, its makeup and its work and more about gaining value by creating value, we succeed, I think.

Technorati Tags: Literature, Programming, Visual Studio, User Experience, UX, Governance, IronRuby, Ruby, Archtecture, Enterprise Architecture

EA Functions Best as a Collaborative Community

2009-05-19T15:42:04.457

Mike Walker responded to my "Is Enterprise Architecture Declarative or Imperative" question with some great thoughts that I'd like to respond to and expand upon here.

For starters, Mike mentioned that he doesn't really care for the terms declarative or imperative. I suspect, based on the tone in the rest of his post, that his dislike stems from the cold and mechanical way those terms may sound when used to represent people. In addition, I think that some would interpret, as Mike did, the declarative term as implying a command and control structure in the sense that EA is still telling teams "what" to do. I'd be willing to grant Mike that those are reasonable arguments, but I will also say that the question was never about the choice between declarative or imperative. Rather, the terms "declarative" and "imperative" represent the "world view" an EA team adopts when sitting on one side or the other. In my mind, declarative teams foster a collaborative community, while imperative teams concern themselves with frameworks, governance, models and the "ROI of EA." Not that these things aren't important, it's just that community and collaboration are more so (a la "Individuals and interactions over processes and tools" in the Agile Manifesto).

Beyond the terms used to frame the debate, I am in complete agreement with the remainder of Mike's post. The key, Mike says, is that EA is about "fostering community, providing the frameworks for decision making and providing assistance on mission critical projects." I think that the real key word there is community. We know frameworks in EA (too well at times) and we know assistance (though we might know it by the word governance often), but I think we tend to shy away from community because it's very contrary to most of the hierarchical organizations in which we find ourselves. But it is without that community that EA is "...viewed not only as Ivory Tower but as traffic cops" as Mike stated. With community, EA is able to voice the strategies of the business and speak from it's unique vantage point, while at the same time empowering and trusting teams to take the expertise and input of EA and bring it to bear on their projects.

That being said, just saying that EA needs to foster a collaborative community is not enough. I have found that the EA/ SA (or Domain Architects as Mike calls them, a term I like quite a bit) interface can also foster confusion and generate conflict in many cases. I think that EA's and SA's could both function better in collaborative roles if they remember a few things about themselves and their comrades.

For Enterprise Architects:

People deserve the benefit of the doubt.
Coding or not, the people you serve (SA's) are deeper in the code than you are.
Seek to serve, not command.
Even if you have the final say in a matter, help people understand your reasons and solicit their feedback early and often.
Respect their craft.
Keep up with technology and don't lose your edge..

For Solution Architects:

People deserve the benefit of the doubt.
Learn to appreciate and understand the role of EA in your organization. Learn to appreciate the different perspectives which they bring.
If EA is acting "Ivory Tower," have the courage to tell them.
Treat EA as an ally, not a roadblock.

Not necessarily a complete list, but the key is that EA and SA must learn to trust one another in order to foster the kind of collaborate community which Mike, myself and so many others speak of. If you don't see a community like that taking shape in your organization, get one started. And if yours is floundering, ask yourself what you can be doing differently before you point to others or the woes of your organization as the cause of your troubles.

8 Random Things

2009-05-19T15:42:04.163

Thanks to Joe Lewis, I've been hit with a meme. Everyone says they never do these things, but this one sounds harmless enough since I can say whatever 8 random things I want to in response.

The rules for this meme are:

Let others know who tagged you.
Players start with 8 random facts about themselves.
Those who are tagged should post these rules and their 8 random facts.
Players should tag 8 other people and notify them they have been tagged.

Ok, so 8 random facts about me:

I received my undergraduate degree in MIS from Baylor University. Since then (all apart from my full-time job), I have considered seminary, law school (took the LSAT even), business school and seminary again. I enrolled in an LIS program at the University of Denver last Spring, then moved into a CIS program at DU's University College after the faculty decided that technology isn't that important to LIS programs. I'm a vagabond student, what can I say. If somebody is willing to give me a Master's degree where I pick all the curriculum, I think I'd finally be happy. Of course, I could do that now. It's called learning on your own...
A few weeks ago, I started teaching myself Ruby on Rails for grins. I'd been interested for a while, but I finally took the plunge and bought Agile Web Development with Rails, 2nd Ed. I haven't had this much fun doing development in a while.
My dream career is to be a writer (and actually be able to live off of it). I've wanted to be once ever since I learned to read and have written on the side actively since I was eighteen. One of these days, I'll force myself through NaNoWriMo and finally move in that direction.
My wife and I sponsor three children with Compassion International, the organization which I am privileged to serve. The names of our children are Denis (Tanzania), Immanuel (El Salvador) and Ana Maria (Dominican Republic). Last year, I was in the Dominican Republic and was blessed enough to be able to meet Ana Maria and her mother. It was an amazing experience and one I will never forget and I am reminded every day how fortunate I am that I get to do something I love for an organization who is on the front lines of ending poverty.
My Myers-Briggs personality type is ENFP (stealing one from Joe). Apparently, I am an idealist and am also terrible at follow-through.
I love technology, but my hobbies (running, biking, hiking, backpacking) take me outdoors where I feel free without my digital leashes.
I am an avid GTD-er. I love the book, the ideas, 43Folders and all things GTD. Right now, I am actually supposed to be doing my weekly review. I think this blog post (though on my action list) took longer than 2 minutes...
I wish I was as smart as Edward Tufte.

So that's that. Now to pass this albatross on to others:

Now how's that for some structured procrastination?

Greg the Architect

2009-05-19T15:42:03.953

If you haven't run across the Greg the Architect site or videos yet, go there now. A couple of great quotes form the "ROI of the Beholder" episode completely out of context:

"Please note: Sarbanes-Oxley prevents us from providing cake."

"Sorry about the metaphor..."

"The big guy doesn't think that SOA is delivering ROI."

"Come on, who's my SOA ROI VIP?"

"I want ROI dripping all over this thing."

"Product naming contest. Name a product, get a free ice cream."

A Call for More EA Blogging

2009-05-19T15:42:02.78

Saw a post this morning (via James McGovern) entitled "Hello World! Untie the Gardener" by a blogger named ingine. It's a brief and basic call to action for more people to step out and get more ideas and dialogue around EA going. I concur with this call and am seconding it (or thirding or thirtying it). My primary motive for this blog is to get the ideas that float around our teams and our organization out into the world and grind them out. The result will nearly always be a better set than when I started. Most recently for me, the topics and discussion around Declarative EA and Buy vs. Build have only refined and improved my ideas. So hear hear! Let's get more of this going.

When James provided his link to this post, he asked ingine to "...start the conversation by asking specific questions." I'm sure ingine has questions or topics of his own, but I'd be happy to throw out some my random ideas and questions and see if we can grease the skids a bit:

1) What are some proven methods around iterative EA? We've all heard the chant of "Future State-Current State-Gap Analysis-Migration Plan" enough to have it embedded in our souls, but how do we leverage these good ideas in a way that doesn't relegate EA to functioning as a team of Binder Boys?

2) Folks like Simon Guest with Microsoft (and many others), have started to collaborate with the User Experience community (The likes of Lou Rosenfeld, Peter Moreville, Jesse James Garret) for more interplay between Architecture and UX. Is this part of a bigger trend of moving away from EA as process and into EA "for the people?" I, for one, would love to see that happen, but what does that mean for the process- and framework-heavy aspects of traditional EA (I'm looking at you mister Zachman)?

3) How does well-run EA best serve an organization first instead of worrying about controlling its decisions? On that note, how does well-run EA best serve its stakeholders first?

4) Is Microsoft on to something with this OBA thing? For that matter, are we really there with Composite Applications? Personally, I see this very idea as an evolution of Enterprise Architectures which serve the user by creating naturally productive applications, but what do others think?

5) How can an organization already in bed with a major software vendor more towards welcoming open source where it makes sense? What experiences have others had in this realm?

6) Is ECM mature enough to be of strategic value to most organizations, or does the visible lack of standards and market volatility mean that we aren't there yet?

7) Is it okay to have a list of random EA questions and not ask any about SOA?... crap.

I'll stop there for now, though more are bouncing around. Some of these are already in my blogging queue, but I'd love to hear from others on any and all of these. Let's get some dialogue going...

EA - The Art of Declarative Constraints?

2009-05-19T15:42:02.593

Last week, Todd Biske linked to my post, "Is Enterprise Architecture Declarative or Imperative?" and added some of his thoughts in a post entitled "Transparency in Architecture." In addition, Adnan Masood left a comment in the original post which made a similar point. Their point: Enterprise Architecture is declarative, but not always and it's not that simple. Adnan agreed that EA is declarative at its best, but mentioned that the "sync up" process I referred to between EA and Solution Architects will have some imperative qualities. Todd also agreed that EA is declarative, but said "... I wouldn't go so far as to say that the path to execution falls to solution architects." Instead, Todd said that EA should define both future state and some very coarse executable actions for achieving that future state. A great point, and I totally agree. The idea of "increasing constraints" as Todd puts it, is a good way to describe the healthy tension at the EA/ SA handoff. Our VP of IT calls this "Freedom within a Framework," a term which I believe captures the essence of how EA can be declarative. We're not going to sit in your code reviews, but we do care how you are using Enterprise Information and upon which platforms you are delivering solutions to our customers. I heard Gartner Analyst Anne Lapkin once state that EA constrains IT for the good of the business. So, If EA is both the Keepers of the Flame and the stewards of strategy, we have to care. And you, whomever you may be, should demand that we care so you can be free to care about what you need to, be it well-run projects, well-crafted and innovative solutions, or a well-thought-of and profitable IT organization.

The second part of Todd's post discussed the topic of governance and how projects constrained by EA should be transparent. While I like this idea far better than being pulled into a million meetings (or, more importantly, making teams feel that they can't be trusted and must be looked after), that kind of transparency is a tall order in most situations I've been in, which Todd also states. But I like this idea and can see its parallels to the concept of Information Radiators in agile software development. In the same way that I can wander into a war room or bullpen and find out basic and essential information about a project (backlog, burndown, etc), these "Architecture Radiators" could provide me with the information I would need to asses the state of the architecture of the project and track its evolution over time.

But that's just theory... what would such a thing look like? It would have to be both simple to maintain and useful. I'll have to think on this some more. In the meantime, does anyone have any ideas or examples from projects where these types of Information Radiators existed?

Technorati Tags: Enterprise Architecture, Solution Architecture, Agile, Information Radiators

The Great Buy Vs. Build Debate - Part IV

2009-05-19T15:42:02.393

Ok, so enough of all of the talk about the nuances of this principle. I've added so much content to its explanation that if I were to append these last three posts to the original explanation, no one would ever read it. So as I wrap this series of posts up, I'm going to sign off with some guidance around these principles. Concrete statements that may help to avoid the three confusion points I covered when I introduced this series. So here they are, with links back to the original post.

Principle: Prefer Packaged Solutions

Guidance:

Putting it another way, Leo De Sousa shares some principles of his own on this topic. He's much more succinct than I am and they are right on the money.

Do these sum it up? If not, feel free to comment and provide some of your own thoughts.

Technorati Tags: Compassion, Architecture, Principles

The Great Buy Vs. Build Debate - Part III

2009-05-19T15:42:01.93

So far, I have discussed how the "Buy vs. Build" principle is designed to encourage teams to choose solutions based on their Purchase, Configure and Build mix, and to help the customer understand how our purchase decisions affect what requirements can be met and how. In this next section, I'll discuss how the "Buy vs. Build" decision is a continual and iterative assessment as opposed to a one-time effort.

More than one Buy Vs. Build Decision Exists

Often the "Prefer Packaged Solutions" principle is assumed to mean that one should be on the lookout for a single software package that provides a close fit to our customer need. We then find the best thing, buy it and we're on our way. But in reality, most IT projects, at least at Compassion, are a bit more complex than that. The problem may walk like CRM, and it may talk like CRM, but oh, they need Digital Asset Management as well. On the other hand, buying a full-stack package might be overkill when the customer just wants to track conversions from the web. Buying a single packaged solution often just doesn't cut it (no matter what the ECM vendors tell you about their shiny hammer). As a result, I believe that the principle is best applied when we buy as much as we can (but not too much), and build the rest. Let's consider two scenarios...

Horizontal and Vertical Purchases

Sometimes, teams find themselves in a situation where the best purchased fit for their business need includes laying a piece of infrastructure which has yet to be purchased. If that happens (and when it rains it tends to pour), said team now has the pleasure of laying some infrastructure. I've heard this referred to "taxing the project teams" and I will say that it's a known pain point that we're trying to fix. Let's hope we do so before someone breaks out the tea. However, even if said infrastructure were already in place, a project team "buys into it" when they choose to invest their vertical and their goodwill into that platform. Thus, a purchase decision is still being made, even when the purchase is in the form of reuse (which is the best buy decision of all).

Were we to follow the "letter of the law," we could say that we've purchased something for our project and go on about our business. But this leaves out the vertical business need... your real purpose for being a project in the first place. If we simply check the box that says we've bought something and move on, we miss out on an opportunity to explore reusable and packaged options for the vertical (From ISV plug-ins on a platform like MOSS to domain-specific guidance and recipes built on top of a Software Factory). Granted, verticals tend to be domain-specific and a bit harder to pin on a tool, but as I said in my last two posts, I believe that we have an obligation to asses our purchase and configure option against the customer's requirements (along with them) to determine if we really can find a fit on their vertical. I think that software is moving more and more up the vertical in any case and am finding that we have more and more reasonable purchase options at our disposal.

Assembling a Package

The other scenario, which happens less likely now but will become more prevalent over time, is when requirements dictate a solution that can't be met with a single purchase, but for which several partial solutions are available (all over the PCB Continuum). It's in these cases where maximizing what you can build has the most power. Here's an example: we are currently working on an effort to provide an "Offline" capability for a select number of business critical applications so that they can perform critical work when they lose connectivity to the WAN. This solution has some typical requirements, like local storage and synchronization, but it also has some requirements around remote workflow and collaboration which complicate the issue a bit. I have spent some time this week assessing a series of tools which could help meet these needs and have found, as expected, that there is not a vendor out there selling "Compassion's Offline Framework 1.0." Instead, I think that the solution chosen will end up being a mix of a few packages, some configuration and some construction by a development team (the sync engine seems a likely candidate). To help illustrate this to the team involved in gathering requirements, I created the chart to the left (you can click it to enlarge) which illustrates each of the 15 options on the draft list (within their area of primary functionality) and placed them on the graph in such a way to illustrate how much of a "buy" we are getting and how much that option meets our requirements. The point I hope to illustrate to those involved is that there is no single package for this problem, but that we don't need to build something from scratch either. As a happy medium, I believe that we can compose a solution from some key complementary technologies on this graph. We would start by going off on a spike or two and really vetting some of these out, of course, but I think that we can come up with a framework that can be leveraged by all of our current and future applications needing an offline capability.

In both scenarios, the common thread is that preferring packaged solutions means we prefer to buy as much as we can, then we build the rest. And the common thread through all three of these posts is that "Preferring Packaged Solutions" means that as stewards of the mission of Compassion International, we have a responsibility to use our resources (money, people, talent, etc) wisely. This doesn't mean we don't build, it just means we target building to those areas that are unique and important to our customers. We have very talented developers, so we have the resources to build. The problem is, they're overloaded and they end up being supplemented with contractors who often get to do the "fun stuff" that they ought to be doing. If we apply this principle well (and I think we do oftentimes), those guys and gals will get to build where it counts and really make a difference in the solutions we deliver to our customers.

One more brief post to recap and sum up, and then on to other vistas...

The Great Buy Vs. Build Debate - Part I

The Great Buy Vs. Build Debate - Part II

Technorati Tags: Compassion, Architecture, Principles, MOSS 2007, WSS 3.0, Dojo, Adobe AIR, Smart Client Software Factory, Groove, Colligo Contributor, AJAX, SQLite, Google Gears

Is Enterprise Architecture Declarative or Imperative?

2009-05-19T15:42:01.197

When I was working on The Great Buy vs. Build Debate - Part II last week, I briefly mentioned that the configuration of a purchased application often takes the form of declarative programming, where a developer instructs a system in what to do, but leaves it to the system to decide how best to implement that instruction. Contrast this with imperative programming, where the system is told both the what and the how. In a moment of rabbit-trailing, I started to think about these terms as they relate to human systems. Specifically, I wondered: Does Enterprise Architecture, as an organizational function, serve better by interacting declaratively with implementing teams, or should said function be imperative in nature? Personally, I think that EA is meant to be declarative and should interact regularly with a group of implementing architects (we refer to them as Solution Architects) who "sync up" with these declarative visions and translate them into execution.

However, I think that in order for an EA group to truly be declarative in its interactions with other teams, there are a few things that have to be in place:

- An official and accountable group of SA's;

- A high degree of trust both within and between the EA and SA groups;

- Clarity of vision/ strategy and communication from EA to SA's;

- A healthy and consistent feedback loop from SA's to EA.

I think that without these (and others, I am sure), the EA function is almost forced to have two feet in both camps, which is frustrating to both the EA team and the SA group, be it "official" or not.

But forget about my opinion: What do you think? Is EA truly meant to be declarative? What else belongs on the list of EA-SA collaboration prerequisites? I'd like to elaborate on this discussion more in future posts and would love some dialogue and feedback.

Technorati Tags: Architecture, Enterprise Architecture, Solution Architecture, Business

The Great Buy Vs. Build Debate - Part II

2009-05-19T15:42:01.003

... software solutions today simply cost too much to build and maintain for the end customer, and we now live in a market where the supply of quality software cannot meet the demands. In order to achieve that, several key pragmatic things must happen, compromises if you like, to meet that demand. Primarily, most software requirements need to start being standardised, and custom software requirements become the exception to the rule - not the norm.

- Jezz Santos, InfoQ Interview on Software Factories

At the end of my previous post, I stated that "Prefer Packaged Solutions," or the "Buy vs. Build Decision," is really about pinpointing a project's Purchase, Configure and Build mix on the PCB Continuum. In this post, I'll discuss those three aspects as they relate to satisfying customer requirements (via the Requirements Continuum) and what building upon each aspect means both to our projects and our customers.

But before I do, an editorial note: I stated in my last post that this entry was going to be about how both IT and our customers don't fully understand the implications of this principle and I have since realized that that's not entirely true and comes off a bit negative to both parties. The real key here is not whether or not we or our customers understand hidden implications of this principle, but that as IT, we communicate with them about what it means to purchase, configure, then build to create a solution that meets their business needs. On with the show...

Customer Implications of a Buy vs. Build Evaluation

Chances are, you've heard about the 80-20 Rule (or Pareto Principle) enough times to be sick of it. And while I sympathize, it's overuse is, I believe, a function of its power and applicability to most systems. Broken down into abstract cause and effect, the 80-20 rule states that 80% of the effects in a given domain are a result of 20% of the causes. According to the Free On-Line Dictionary of Computing, the 80-20 Rule is the "... program-design version of the law of diminishing returns. The 80/20 rule says that roughly 80% of the problem can be solved with 20% of the effort that it would take to solve the whole problem" (see http://foldoc.org/?eighty-twenty+rule). Since "effort" also means "cost" in the case of software, I like to extend this rule to say that a customer can obtain 80% of their desired functionality at 20% of the total cost. The real rub though is:

Where the 80% lies along the continuum (in Configuration or Build);
and, if 80% isn't good enough, where to stop;

So, as we architect a solution for our customer, how do we move to the right spot on the continuum?

Buying a Packaged Solution

It all starts with purchasing something. That something may be large or small, expensive or free. It may be done more than once (as I'll cover in my next post), but you're always "buying something." The key, though, is buying the biggest thing you can without wasting the customer's money. For example, if the customer wants basic document library and list services in their app, you probably shouldn't buy Documentum. On the other end, you shouldn't custom build a package that provides these services if Windows SharePoint Services is sitting on your servers. A bit simplistic, but you get the point.

Once you've determined the correct solution to buy, you can determine its ability to meet customer requirements out-of-the-box (OOB). By that I mean: if you installed the application and made it available to the customer with no changes to the app whatsoever, what percentage of their requirements would be met? Often this is a small percentage and, in many cases, the things that are met are requirements IT usually adds on behalf of the customer, like role-based user administration, ability to recognize AD accounts, security trimming and the like. However, requirements like a consistent Look and Feel (UI) and a baseline database schema upon which the application is built also figure into the calculation as these are things that tend to take quite a while when building an application from scratch. Understanding exactly where the OOB solution results in met requirements is essential to knowing the final mix of configuration and building because it establishes the starting line on the Requirements Continuum, as in the illustration on the left. My placement is probably a bit high for most bought solutions, but the intent is to illustrate that there will always be a gap between the requirements met with the purchase, the those still remaining. I covered this in more detail in my last post.

Here's where facilitating customer understanding of this principle comes in. After determining where the purchase lies on the requirements continuum, we've reached an important communication touch-point with the customer. While it's probably not necessary in all cases to give the customer a complete breakdown of what needs are already met (though we may want or need to), the key here is simply letting the customer know that there will be extra cost involved in configuring or building on top of this solution. At that point, it's time to determine how much configuring and how much building (if any) needs to be done.

Configuring a Packaged Solution

Since there is no such thing as a bought solution, you'll always find yourself along this portion of the Requirements Continuum. Even packaged solutions targeted to meet a specific business need like CRM, ERP or ECM cannot align to a specific organization because each organization performs the processes that drive those applications in distinctive ways. In some cases, these distinctions are small, as in "we prefer to use the term 'prospect' instead of 'lead' in our CRM systems." Sometimes they are a bit broader, as in "The lead form should capture lead source and some freeform textbox for entry of interests." In other cases, the distinctions are large, as in "When a content producer publishes a document, it should be approved in sequence by 4 separate individuals." However, in flexible systems (which should be part of our evaluation), these three requirements can often be met by configuring the existing system to provide this functionality. A mentor of mine often referred this to as Declarative Programming, because implementation of the requirement manifests itself by telling the underlying system what to do and not how to do it. Here's an example: In Microsoft Dynamics CRM 3.0, the modifications to the UI for lead entry form mentioned in the second requirement would be implemented by declaratively adding these fields to the form through the tool itself, as opposed to imperatively adding this information directly in the ASPX form, then wiring it to the database.

This product-supported configuration, as illustrated in the updated Requirements Continuum on the left, is where the bought solution is extended, based on customer requirements, until the upper-limit is reached, whether that be 80% of the overall requirements or not.

At this point, the second customer touch point comes into play. The requirements remaining after purchase and configuration then becomes a list of extra functionality that might be a bit more costly than what has been accomplished so far. However, if the customer needs that functionality and is willing to pay, it's time we do some building.

Building to Extend a Packaged Solution

If you've reached this point, your customer has expressed a desire to obtain functionality that is only available by extending the solution with custom-built code or extensions. Harkening back to the 80-20 Rule, it's important for the customer to understand that these requirements are typically more expensive to provide than those that were met through purchase and configuration. Thus, this is where the final 20% of desired functionality starts to make up 80% of the total cost of the solution.

That's not to say one should never build. In fact, it may often be necessary to build at least something for the customer that they can't get any other way, but which they need. This is why our the "Prefer Packaged Solutions" principle, states that is acceptable to build "critical capabilities which cannot be satisfied by a purchased application." (see Part I for the full text) Thus, here we should guide the customer to select that functionality which is considered "critical" to the solution being provided. Oftentimes, these things are not only critical, but also unique to the problem domain or organization, as illustrated in the complete requirements continuum depicted above.

The challenge here, of course, is helping the customer understand the fine line between "must have" or critical and "nice to have" requirements. It's often vital to have workflow that works, but it may not always be necessary to have fine-grained control over the placement of form fields. However, uniqueness means that anything is possible at times.

To this point, we've covered the true meaning of the "Buy vs. Build Decision" (via the PCB Continuum) and the customer implications of that decision (via the Requirements Continuum). In the third post on this topic, I'll discuss the reality of multiple "Buy vs. Build Decisions" in a given problem space.

The Great Buy Vs. Build Debate - Part I

Technorati Tags: Compassion, Architecture, Principles, Software Factories, CRM 3.0

Here's To Number Four!

2009-05-19T15:42:00.84

Those of you who know me, know that I grew up in San Antonio and am a life-long Spurs fan. Needless to say, I am quite happy this morning. Here's an image to ponder:

Technorati Tags: Spurs, NBA

The Great Buy Vs. Build Debate - Part I

2009-05-19T15:42:00.683

The team I work on at Compassion created a document a few years back called Compassion's Corporate Architecture Principles, or CAP. This document consists of a series of high-level principles meant to encourage IT development teams to consider the enterprise when they develop a solution to meet their given business need. Our team, the Architecture Office, or AO, reviews each project during elaboration (most of the time) and evaluates said project against these principles to determine if it passes muster. One of the most oft-discussed principles these days is "Prefer Packaged Solutions." Here is the statement:

Compassion should "build" only those applications that cannot be purchased or that can be shown to offer critical capabilities that cannot be satisfied by a purchased application.

Even though these principles were adopted before I joined the AO, I like this one because it is intended to encourage Compassion IT and its development teams to pursue reuse at the highest levels possible (i.e. entire packages, services and modules rather than simply "code reuse"). If possible, teams are encouraged to buy an application (or set of applications) which meet the business need of their customer. This statement is clear and even includes the criteria in which building is acceptable ("critical capabilities which cannot be satisfied by a purchased application"). Rhetorically, we refer to this principle as the "Buy vs. Build Decision."

Call me a biased architect with visions of Composite Applications running through his head, but I think that this principle is one of the most important we have. However, this principle is often minimized, misstated and mostly misunderstood, and I think that happens for several reasons: first, there is no such thing as a pure "buy" solution; second, both IT and its customers don't fully realize the implications of this principle; and third, most IT teams are faced with more than one Buy vs. Build Decision. I'll elaborate on the first in this post and will cover the second and third in subsequent posts.

No Such Thing as a pure "Buy" Solution

When considering the "Buy vs. Build" principle, both managers and customers tend to get the idea that they are buying a met business need once the check is signed, when this is hardly ever the case. Instead, purchased solutions usually must be configured to meet the business need (skinning, adding modules, populating data, etc.), enhanced via custom code or other custom development, or both. I refer to this as the Purchase-Configure-Build (PCB) Continuum, which is pictured on the left. Most of the time, the closest you'll get to a bought solution is one you purchase, then spend additional money configuring for the customer (This means that the purchase price is not the final price, by the way). The no-mans land is the 100% build, which is today's age of frameworks like .NET and Java pretty much isn't done by anyone's definition. Between the two is a combination of purchasing, configuration and building that results in a met business need. Let's look at an example in Microsoft Office SharePoint Server 2007 (MOSS) and Windows SharePoint Services 3.0 (WSS). WSS 3.0 is a site-provisioning engine which provides basic content and document management services to users via SharePoint sites. WSS is also a development platform upon which developers can configure and construct solutions using documents and lists, WebParts and Workflows that leverage Windows Workflow Foundation (WF). MOSS 2007 sits on top of WSS and provides a series of value-added extensions to WSS like site federation, search, Forms Services, out of the box Workflows, etc. The image below illustrates where each of these lands on the PCB Continuum. Obviously, WSS by itself can be leveraged and extended to meet a business need, but doing so often requires plenty of configuration, development and administration. A tool like MOSS is designed to minimize the cost of those customizations by providing extra services which IT may leverage, thus it sits more on the buy side of the continuum. But it's not all the way on the buy side, again because no bought solution can ever completely meet a customer's business need.

Because a continuum exists between the purchase and construction of a given solution, it's never so cut and dry that we can simply check a box and say that we're buying this time, or not and say that the customer's needs are too unique. The Buy vs. Build Decision is oftentimes a mix of what can be purchased for a customer (i.e. WSS for web-site hosting and basic collaboration) and what must be built in order to satisfy their business needs (i.e. Custom approval workflows) and it's the job of the AO and the Governance process to ensure that an appropriate mix is pursued. We'll see more on the complexity of that decision and its implications in the next two parts.

Technorati Tags: Compassion, Architecture, Principles, MOSS 2007, WSS 3.0

Forward Pass Redux 2006

2009-05-19T15:42:00.457

100 years ago today, the forward pass was "invented" in football. It was less than a year from first use to when the forward pass was added to the football rulebook.

This got me thinking. What would happen if the forward pass were invented today?

Some ideas:

ESPN.com would unleash articles from their masters with opinions on either side of the argument. Len Pasquarelli would probably claim that the forward pass dilutes the purity of the game and should be sqelched immediately. Mark Schlereth would claim that America needs to wake up and recognize that Football is a business and if the business needs to evolve to attract fans, it should be allowed to do so.
Bill Simmons would, of course, weigh-in in some humorous way (that manages to cull from 80's pop culture, music and movies) and generate a ton of fan mail from smarmy frat boys who engage in textual one-upsmanship by emailing questions like:

Hey Bill,

Is it me, or are leather helmets a 10 on the Unintentional Comedy Scale? Also, I'd like to submit Jack Schneider as a member of the Ewing Theory team. I mean, he couldn't catch a forward pass if the ball was a Koosh and was lobbed underhanded!

More Cowbell,

Pete in Yonkers

How about in the world of politics. Of course, the politicians can't help but get involved:

Democrats would claim that the forward pass was a ploy by Republicans to divert attention from the war in Iraq during mid-term elections. Then they would question whether the forward pass is a sign that steroids are a problem in football and organize commitees to investigate the possibility of government regulation of the sport.
Meanwhile, Republicans would claim that the forward pass is the work of Al-Qaeda and an attempt by international terrorists to attack us by changing our way of life. A vote for the Republican party is a vote against Al Qaeda!

Of course, the forward pass would never survive the media frenzy, Bradbury Robinson, the offender who dared to throw the pass would be demonized (along with his coach, Eddie Cochems) and the sport of football would remain in the stone age forever.

Just kind of makes one think... Maybe I am just making generalizations, but wouldn't you agree that all of the things I listed above, funny or otherwise, aren't really that far from the realm of possibility?

Sports, Football, Forward Pass, Bill Simmons, Politics

Flame Wars 2006

2009-05-19T15:42:00.29

I am an avid reader of Joel on Software. I read the book and actively follow the blog. I admire Joel, his career and his willingness to speak his mind. I don't always agree with Joel, but I always respect his opinion. He has a fundamental way of looking at seemingly complex things that can tend to oversimplify the issues, but they can also bring about understanding and foster discussion.

Apparently, his Language Wars post from last week upset DHH, a self-described "Emo Programmer," because Joel claims that Ruby on Rails isn't "Enterprisey" enough. David doesn't seem to agree and claimed that Joel's post was a textbook example of FUD in action. If this turns into Adam Curry v. Dave Winer, it could be interesting to watch.

Now I am probably out of line in declaring this a flame war when Joel has yet to provide a direct response to DHH. But DHH is doing his best to shake the trees. See Exhibit A, Two posts and two updates to the second post all in the course of one day.

DHH missed the point of Joel's post, which was to say that for enterprise applications (read: internal) there are only a limited slate of options (.NET, Java, PHP and 1/2 Python). I think he's right. And don't get me wrong... I really like Rails. I love the flexibility; I love the simplicity. I love the "fight the power" attitude that comes packaged with the bits. I have used it a bit on the side and will continue to do so when free time lands in my lap. I've even considered repurposing this blog in Rails to add some AJAX-y goodness.

But Joel's point goes beyond the classic "My programming language is cooler than yours" mentality that populates playgrounds and UNIX circles. It's not about cool or fun or exciting. It's about what the enterprise can tolerate and is ready for. When we make architectural decisions at Compassion, we always consider context. Context is king. It dictates what you can afford to do with what you've been given. Context also brings in factors like how risk tolerant your customers are and what your Machine Service Bureau (MSB) or support group is willing to maintain.

37Signals is changing the world with their software, and that's not an understatement. Do I want to use Rails in house at Compassion tomorrow? Of course, I'd love to give it a spin on something internal. Is that a wise decision based on my current context? Not for another year or two, which is exactly what Joel meant. When the Enterprise is the customer, that's a reality.

All that being said, Joel is missing something here as well. Rails may not be in Joel's short list now, but I'd be willing to bet it will be before Python makes the skip to a full option. Why? Because Rails in the poster child for agility and getting things done with software. It doesn't matter that Python has some of those flavors. Ruby on Rails is a term executives are hearing. Rails is also the poster child for AJAX and when AJAX crosses into the enterprise, so will Rails.

In addition to that, the ubiquity of SOA in the enterprise may make all of this moot eventually anyway. Think about it: If my enterprise has a fully-loaded SOA with all the ESB bells and whistles, why couldn't development team A create a rails application that used services provided by Infrastructure team B? As long as team A's app can create and consume the right messages (and don't even assume SOAP... a good ESB can translate REST to SOAP and back again) who cares what stack team A uses (assuming team A will be dogfooding said app)?

In my opinion, all of this is just smoke and wasted bits when we're in the middle of a technology shift that is enabling these things to play together. So if personal preference becomes the rule of the day (which Microsoft certainly supports by creating languages in .NET that all compile to the same MSIL code) when will these silly schoolyard squabbles stop?

Ruby on Rails, SOA, Joel on Software, Loud Thinking, DHH, .NET

The world is spinning, or is it me?

2009-05-19T15:42:00.13

Since I last crafted a legitimate post to this blog, I have enjoyed several months of changes, excitement, bombardment and general much ado about everything. Here are a few highlights: 1) Finished my first Quarter of LIS in one piece.

2) Spent a week in the Dominican Republic leading a Men's Conference with 3 other men.

3) Was promoted to a new role at Compassion as the Enterprise Applications Architect. I am currently ramping down on day-to-day development work and ramping up (quickly!) into that job. It's been a lot of fun so far, except the part where I tried to work on all tasks old and new for about two months.

4) Spent 3 days (starting the day after I got back into the country) in San Diego at the Gartner Enterprise Architecture Summit. That was a fun way to get started on the new job, esp. as I got to attend with my new boss.

5) Decided not to take class during the summer Quarter (see #3), but I am getting ready to start the Fall Quarter on September 12. I'll be taking two courses:

The Corporate Information Environment
Legal Issues in Knowledge Management

I am looking forward to those. Not so much the cost of the textbooks, but I am looking forward to the classes themselves.

6) Compassion is at the end of a building expansion and parts of the IT department have been cube and office-less this week. One good friend also managed to find a way to move into a new house this week, I think he's been sleeping at Panera Bread. As a side note, it's too bad that good ideas always come to me too late because it would have been cool to have everyone that has been misplaced to take pictures of where they were working this week. I alone have worked from:

My boss's office - He's on vacation this week.
The World Prayer Center at New Life Church (Colorado Springs)
The Lobby of New Life Church
Panera Bread
My house (This can be further sub-categorized into: the dining room table, the couch, a recliner and on the deck... I am a restless creature)

And that about catches you up to date (assuming you're still reading). The good news about the move this week is that it has given me a chance to catch up on some much needed research, reading, brainstorming and planning for the new job (with a little coding thrown in). Some more in relation to my new job: Obviously, this blog was created to be a place where I threw half-baked opinions about UX design against the wall. That was fun for a while, but then my ADD took me to some content about developer stuff related to all the goodies from last years' DevConnections conference. That was also fun for a while. All that being said, I think that this blog has never really had the unique personality that it needed to. What's cool is that my new job has created some interesting synergies between that developer in me (still there Ken) and the guy that thinks that UX matters. Case(s) in point: 1) When I attended the Gartner EA Summit, I heard a great talk by Harry Pierson called Beyond SOA: Understanding the User's Role in Architecture. Hey, that sounds like something I would enjoy... That was the first sign that I may not have strayed to far after all.
2) I found out after I got back and I was poking around that Simon Guest had given a talk at TechEd entitled Putting the User Back into SOA that I managed to grab the slides for. The second sign... (BTW, that link does not link to the slides themselves. I can't seem to find them anymore, nor do I remember how I got them. For the next best thing, you can head over to this link where Simon links to an ARCast episode he did with Ron Jacobs on the same topic.)
3) A couple of weeks ago, Simon posted once again about UX. This time, he was announcing a Forum discussion he will be hosting in California on "...the intersection of Architecture and User Experience." The third and final sign...
This was an exciting set of circumstances for me because I felt in my gut that those old passions were still important and had a place in my new role. This was just some great confirmation. The SOA aspect of this was especially interesting as some aspects of an Enterprise SOA have been rolled out at Compassion and we will continue to look for ways to use it to craft a larger Integration and BPM Platform. For more info on Compassion's SOA Implementation, Dan Fox, our resident Solutions Architect, Microsoft MVP and all-around genius has been posting about it at length. Check it out here. So what does all this mean then? It means that I will continue to blog (or start depending on your definition of 'continue.') about UX, but from a slightly different perspective. I will continue to talk about UI design and UX for the web, but I will also begin to incorporate some SOA, SaaS, BPM, Architecture and even Knowledge Management 'stuff.' If you actually read this far, my hope is that you would either a) stick around and continue reading what I write; or b) start today. I'm no expert on any of these subjects, but I love to read, write and discourse on nearly everything. So here's to a new phase in the journey. Stick around... let's hope I find reason to turn my entry in your FeedBurner client bold a bit more often. UX, BPM, SOA, SaaS, Architecture, Gartner, LIS

Thanks Merlin...

2009-05-19T15:41:59.963

Most of the time, the musings of Merlin Mann save me time... not so today after he linked to the "Official Seal Generator." Of course, I could blame it on the fact that I am working offsite due to a building move at work, but I'd rather blame Merlin. Anyway... Here are a couple of logos I generated for this site:

Official Seal Generator, Fun