Note: Cross-posed from Paul Rayner’s Blog.

Last week, I had the opportunity to co-present with IASA Denver chapter president Paul Rayner, at the IASA Austin ITARC Conference. Our presentation was titled “Keeping Architectures Relevant: Using Domain-Driven Design and Emergent Architecture” and is meant to be a helpful introduction to key ideas around DDD, Agile and Architecture, with an emphasis on how an architect can use principles and practices from each of these to keep themselves and their work relevant.

Our presentation was meant to be a brief overview and introduction to the ideas we’ll be covering in our upcoming article (by a similar name) in the Architecture Journal. See my last post for more information about that article. Watch for a link here in mid-March when the article is released.

As Paul states in his post, we really enjoyed presenting and got some great questions during and feedback after the session. We’re planning to give this presentation again soon, so if you were there and you have any additional feedback to offer, we’d love to hear it. We’ll be cross-posting additional content related to the paper and this presentation over the coming weeks, so keep an eye peeled here and Paul’s blog.

Paul Rayner and I recently submitted (and had accepted) a proposal for an article in an upcoming issue of The Architecture Journal. The issue, #23, will center around Architecture Modeling and the tools, tactics and strategies an architect can leverage in modeling his or her architectures.

We’re knee-deep in drafting the paper right now, and it won’t come out until mid-March, but I did want to share the abstract we submitted so you can see what we’re scheming. We’d love to hear and thoughts, ideas or suggestions you might have. 

“Keeping Architectures Relevant: Using Domain-Driven Design and Emergent Architecture to Manage Complexity and Enable Change”

Abstract

Too many systems seem to become legacy upon release, while some never even have a chance to move into production before they are undermined by the calcification of unmet expectations and mismatched domain needs. Regardless of the design effort early in the lifecycle, neglecting the domain model and producing inflexible design results in the increasing irrelevance of the initial architecture of a system. The accidental complexity of that system rises and communication between developers and customers deteriorates. Changes and new features become more difficult to accommodate as the richness and value of the system's essential complexity is eroded. Sustainable and successful software development is all about managing complexity and enabling change, and successful architects create designs that clearly address both.

Architects, domain experts and developers collaborate to mitigate complexity through strategic modeling and design. This requires a focus on the core domain and the continuous application of germane design patterns. Ongoing effort should be expended on defining and refining the domain model through the establishment and exercise of a language that everyone shares. The development of this ubiquitous language, along with the use of domain-driven design techniques, enables business problems and their solutions to be expressed through rich domain models that are both meaningful to business experts and executable by the development team.

Keeping our architectures relevant also means enabling change. As architecture is allowed to emerge, evolve, and mature, it becomes a true reflection of the deep understanding of both domain experts and developers. Architects who expect their initial design to evolve, and who design with evolution in mind, create architectures that deliver a strong competitive advantage to the business.

Reader Takeaways

1) The establishment of a ubiquitous language, which removes the built-in translation layer between domain experts and the development team, is key to relevant modeling.

2) Domain-driven design enables the articulation of a distilled architecture through models that mitigates complexity while remaining relevant to the business and clear to the development team.

3) Architects must collaboratively drive architectures which emerge, evolve and mature in order to deliver systems that improve in their ability to respond to the changing needs of the business.

I had a great time at IASA Denver last night. My presentation included some great discussion among the group about workflow systems and the various challenges we all face when addressing a “workflow style” problem.IASA Denver is an amazing community and a real example of how a professional group should be run. Many thanks to Paul, Kevin and Tim for starting and leading such an amazing group. If you’re in CO, consider yourself an architect and aren’t an IASA Denver member, you’re missing out.

If you’re interested, I’ve posted the slides from my talk at SlideShare and have embedded them below. You can also get the slide deck and the code from both of my demos at http://github.com/bsatrom/WorkflowSystems

Now to continue a productive week in CO with the Thought Ascent crew!

In a couple of weeks, I’ll be heading back up to Colorado to do some planning and brainstorming with the Thought Ascent HQ guys and also to speak at the Denver chapter of IASA.

The topic: Workflow Systems.

I spoke at the RMTT back in February about Workflow, specifically Windows Workflow 3.5 (you can still find the slides and code here, btw).

This talk will be nothing like that one.

Different audience, different goals.

Here’s the abstract if you don’t believe me:

Workflow Systems: Myths, Truths and Wishful Thinking

"If workflow is simply about the coordination of work, why is it such a point of contention for most technologists? Do Workflow systems really enable a Business Analyst to change a production process, or are they a waste of time and resources, not to mention a problem that a solid developer could solve with a hundred lines of code? The goal of this talk is to demystify the idea of "workflow," and to discuss what place, if any, a Workflow system might have in your problem domain. We'll discuss Workflow Systems by example with Microsoft's Workflow Foundation tools (3.x and 4.0) and explore popular, low-ceremony options for doing "workflow" (NServiceBus, MassTransit, etc). We'll end the session with an open discussion on workflow tools and collaboratively craft some tactical recommendations on when and why to use workflow in your organization."

So not so much about WF as it is about Workflow in general. The aspects that are about WF don’t make the assumption that WF is a useful tool, or even a good solution, hence the time spent on other options like NServiceBus and MassTransit.

Look for the slides and code to be posted here shortly before or after the talk, along with a couple of follow-up posts (perhaps even a series) that will dive deeper into the main points from my talk.

And if you’re in Colorado, I hope to see you there (click here for meeting details, times and a map)!

Part of what I've been doing since changing jobs back in October 2008 is helping my boss move forward with a non-profit that he's been working on for the last few years. The name of the organization is Brilliant Life, and the goal of the organization is to improve lives and change technology by providing technology training and careers to individuals who aren't being given a chance to pursue those careers today. That includes juvenile and adult offenders, the homeless, displaced workers, etc. It's a great organization and I'm excited for the vision and what we know will come of it.

We're a young organization, but we've had success in CO already. In July, I moved to Austin with my family to both open the Texas branch of the consulting company at which I work (Thought Ascent) and to expand Brilliant Life into Texas. Part of that expansion is a push to get the word out, which is where South By Southwest (SXSW) and this post come in. SXSW is a music, film and interactive festival that takes place in Austin each year. The Interactive portion of the festival draws thousands of tech professionals to hear about subjects from social media to emerging technology to how technology is being used to make the world a better place (that’s us).

What's more, the public is given a role in helping to select the sessions that will be offered for each track.

This is where you come in. We need your vote. We have submitted a session for SXSW under the title: "Turning Criminals into Coders: The Brilliant Life Story." Here's the abstract:

"Can coding literally save someone's life? Can it change America's broken prison system? The non-profit, Brilliant Life, will discuss how they're teaching juvenile delinquents to code, how to work on a software development team, as well as how they’re providing opportunities to work after their prison time ends."

Voting is open to the public, and we've had a pretty good response so far. But we need your vote as well. So, please take a moment to go to the link below and vote for our session. You will have to register, but SXSW doesn't spam, so sign right up.

http://panelpicker.sxsw.com/ideas/view/4435

And leave a comment for us if you can.

Thanks for your support!

P.S. If you're interested in knowing more about Brilliant Life and what you can do to help, email me a brandon.satrom AT brilliantlife DOT org.

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.

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.

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.

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.

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 some tough challenges and trying times, 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.