Architectural Mission


Elwood: It’s 106 miles to Chicago, we got a full tank of gas, half a pack of cigarettes, it’s dark… and we’re wearing sunglasses.
Jake: Hit it.
-The Blues Brothers

I’m on a mission. I’ve been tasked with stewarding a new paradigm in how we build our software here at Lampo. There are many facets to this and being inspired by Kevin’s recent posts I, too, am going to try exposing the process as I go through it. I welcome you to join me on my journey and hopefully we’ll learn something along the way.

A new paradigm.

Have you introduced something new to your organization? It can be met with criticism or fanfare… or both. I’m fortunate to work at a company that believes in the book Who Moved My Cheese. This is required reading for our employees. The essence is that change is inevitable and there are ways to enjoy this process. I recommend reading this lil’ classic if you haven’t already. Some change ends up moving a lot of cheese. Changing fundamental architecture of all applications falls into this bucket.

What is this change?

Simply put we are moving to a service oriented architecture. That’s overly simplified and doesn’t encompass the whole strategy. “One Platform” is more like it. Our existing software is not bad by any means. There’s nothing fundamentally wrong with it. It’s exactly what has made us successful. If you’ve ever had the thought of changing how things are take a moment to remind yourself that your company’s success is based on the state of things today. It’s successful. The new change is untested, and high risk. Proceed with caution!

Why change?

Yes we have been successful. Our current apps have brought us to where we are. Will they get us to where we want to go? No. We’re growing and are experiencing growing pains. This is where change comes in!

We have a fair number of applications. We also have a fair number of capabilities that are similar across many of these applications and are not truly specific to any one app. This includes, but is not limited to concepts such as handling content, managing users, security, user interface and user experience. Kevin’s recent posts on Implementing Modular Web Design is talking about one of these new foundational concepts. We are very decentralized and desire to move to a centralized system.

We’re weaving SOA into our fabric because it fits in with our objectives and our end goal to give hope. Always, always, always know why you’re in business and what you are trying to achieve. This change isn’t something we’re doing because it’s popular, or a great way to impress peers. We chose a direction that fit our team and fit our mission.

Fundamental changes are risky ventures. I’ve heard them called “science projects” and anyone bringing one up was asking for trouble. I’ve known some companies that have almost sunk their business with a “major re-write”. Embracing change also means to understand what’s at risk – both good and bad.

This type of open discussion has helped form our strategies around introducing these changes. This level of change is deep. It effects our estimates, project management, developer communication, code management, testing, deployment process, and governance. Risk management needs to be ever present when every stage of the development life cycle is effected.

Be Confident!

We have an amazing team. I’m confident in my teammates, the mission, and myself. I have no doubt we will be successful. I’m not going to measure success on adhering to a spec or standard on how to implement an SOA architecture. It’s about abstracting out common elements into a reusable toolkit in order to deliver better products quickly.

Elwood: It’s got a cop motor, a 440 cubic inch plant, it’s got cop tires, cop suspensions, cop shocks. It’s a model made before catalytic converters so it’ll run good on regular gas. What do you say, is it the new Bluesmobile or what? – The Blues Brothers

I’d love to hear about your experiences with change! Please respond below.

3 Responses to “Architectural Mission”

  1. Wesley Snider Says:

    Hi Jim,

    I couldn’t agree and identify with you more. I’ve presided over several “paradigm shifts” in the course of my career, and the responses to these changes have been varied and numerous, but in distilling it down to 4 main types, I would agree that “Who Moved My Cheese” is a pretty good summation.

    I reckon…

    In my recent experience, I would say that nary an acronym has caused so much consternation like SOA, ESB, and/or SAAS have. For many, even approaching the abstract notion of “change” sends shivers through the organization, much less beginning to lay out concrete architectural plans to implement SOA enterprise-wide. What used to be your departments private affairs has now been put on display to the world, good or bad.

    When an astute developer steps back for a moment, they begin to see that SOA and ESBs are nothing more than mechanisms to facilitate a larger pattern, OOA (Object Oriented Architecture). Just SOA tends to put more focus on the service methods than the beans and method of exchange. Fine by me.

    To the uninitiated developer, SOA is little more than the service layer of an MVC app, exposed enterprise-wide through a particular mechanism, be it SOAP, JMS/MQ, CICS…fill in the blank. Okay, maybe throw in SSO or federated rights management too, but in the end the REAL goal is. 30,000ft view of the organizations needs, not ground-level, four-walled thinking.

    I’m not sure whether the hardest part is winning converts, or managing inter-team negativity. I know that a die-hard positive outlook (Sniff & Scurry) is the only way to go, and I enjoy being so darn positive that people can’t help but be affected…I can only sell products that believe in, and in this it’s ESBs and SOA. I love em’!

    I’ve made great progress, as a consumate idea-salesman, by explaining to the conflicted parties the varied reasons why it’s in their best interests to think at a broader level. Getting them involved in the discovery phase is a big helper too. Valuing their input and letting them know it…big points.

    So what to do with the disaffected parties? I’ve seen great gains made by splitting and grouping them up by their particular area of grievance, and leading them from their place of disdain and cynicism (4-walled development), out into the light of organization-wide thinking (SOA).

    Salesmanship is a must…

    You know, I’ve also found that when people are finally converted to a SOA mode of thinking, they tend to be even more conscientious and considerate of the priorities and concerns of others. Not just on a professional level, but a personal level too. That for sure is a win-win for everyone involved.

    Hope that made sense and is useful input. I tend to write emotively and don’t always make sense when I’m in a hurry


    (and no, smiley’s aren’t just for girls anymore!!!)

  2. jim siegienski Says:


    Thanks for the response! Keep fighting the good fight. 🙂

  3. Architectural Mission pt 3 – Bottoms Up! « Web Monkeys with Laserbeams Says:

    […] Monkeys with Laserbeams Just another weblog « Architectural Mission Architectural Mission pt 2 – At Your Service […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: