There is no right way (though there are plenty of wrong ones)

The idea of functional perfection is an intriguing concept. Would it not be wonderful if the things we use functioned perfectly? Well … it certainly would … but, then, what do we actually mean by perfectly? On the one hand we tend to consider functional perfection to be an obvious, if difficult, aim of the engineer’s and designer’s effort. But on the other hand we have a creeping suspicion that such an aim is hopelessly out of reach.

Jan Michl, “On the Rumor of Functional Perfection”

One of my pet peeves is being asked for the “right” way to do something. The word “right” only has meaning relative to your perception of the current state of your needs. Zero defects sounds like a great deal until the time and cost is accounted for. Ditto for “five nines” high availability. And eking out every little bit of performance will likely leave you with a system that is difficult to maintain. There is a reason that some drive Volvos, some Lamborghinis, and others Fords.

A major aspect of an architect’s job is to understand the trade-offs that go into design decisions and then with the customer’s wants and needs in mind, creating a solution that best meets those requirements. Where requirements are contradictory, resolutions must be negotiated. It is almost assured that what suffices for today will not be good enough tomorrow. It is equally likely that, despite your best efforts to anticipate future needs, something unexpected will come up. Therefore, the aim should not be for everlasting perfection, but for flexibility.

Aiming for some sort of illusory technical perfection loses sight of the customer’s needs. As difficult as it may be to process, the customer is not interested in your skill. The customer is interested in what your skill can do to improve their business. They are not interested in paying extra for work that does not address that goal. As Dan North noted:

There is a difference between the mindset of a master stonemason sculpting the expression on the face of a gargoyle and someone using the commodity blocks that make up a multi-storey car park. In the latter case the last thing I want is someone’s “personality” causing some of the blocks to be different sizes and no longer interchangeable, never mind the added expense of having someone manually hew the stone rather than using machine tools. In the former the stonemason’s attitude is indulgent. He is putting his signature (and his ego, and his reputation) into this magnificent representation of Hell’s best. If you just wanted an oil-pouring spout you could get one from a DIY store.

This does not, however, mean that the architect’s role is passive. Understanding the costs and benefits associated with design decisions places the architect in a position of responsibility for communicating the trade-offs to the customer. As stated by Rebecca Parsons:

From a business context, the business has a debt that it may or may not have made a conscious decision to take on. It is the responsibility of the development team to make sure the business understands if they are compromising the long-term costs and value of the code by taking a particular decision in the short term.

It is the architect’s job to help guide the customer in choosing a path that provides the optimum system for their needs now and in the future. This is where the architect provides value.

After all, at the end of the day, if there were only one right way to design a system, would anyone need an architect?

Getting a handle on IT costs by eliminating chargebacks?

A recent article on CIO.com listed recommendations from Gartner analyst Ken McGee on cutting costs and improving the tracking of the expenses that remain. In all, McGee outlined 16 items:

1. Measure IT projects against the CEO’s priorities and see if they match.
2. Look at how the company makes money and compare that to the projects that IT is working on, and terminate support of projects that will not improve the income statement.
3. Abandon CIO priorities that do not directly support the CEO’s priorities. The CEO’s priorities are predominately revenue-related, where CIO priorities are mostly cost-related. An example might be a CIO who is focused on improving technical infrastructure, versus a CEO who has set a priority of being more open and collaborative with customers. McGee’s advice is “to end those discrepancies.”
4. and 5. These two are combined: Stop recommending IT mega projects. “You don’t have the money,” McGee said. Instead, discover the weaknesses in the existing portfolio and where investment is needed, he said.
6. Make people accountable for IT spending. Have business units acknowledge, with a signature, the ongoing cost of an IT service they need.
7. Terminate applications that aren’t delivering value. Gartner estimates that operating expenses can be reduced by 20% by 2014 by decommissioning applications.
8. Stop the practice of putting all enterprise spending within the CIO’s budget. It obscures the IT cost of business units. “The CIO ends up being a pinata for the entire organization,” McGee said.
9. IT organizations need to create processes that prevent “surprises,” which disrupt the business model. McGee introduced this point by showing the cover page of the Borders Group bankruptcy filing. It took that company three years to respond to Amazon’s Kindle, he said.
10. Eradicate ” cloud -a-phobia.” The number of organizations that will deliver 100% of their IT services internally is over, said McGee, but there remains a stalling phenomenon.
11. Abandon level 1, 2 and 3 tech support, where the more complex the problem the higher the skill level sought to address it until it reaches the people who built it. Calling a high level of support is like calling an automaker to pull the person from the assembly line who built the part to fix the problem. “This is what we do every single day in IT,” McGee said. Most application staffs are oversized to compensate for the interruptions, and operations staffs are undersized because of their co-dependency.
12. Cancel most IT chargeback systems, which take an extraordinary amount of effort and expense to charge back what is a small amount of revenue.
13. Stop seeking competitive bids. Most companies keep their existing vendor. “The number of people who absolutely terminate their network services contract, for example, and go to a new carrier is a very small universe,” McGee said. The multi-step RFP (request for proposal) process is ineffective and time consuming. Instead, users should reach out to a consulting firm or to their peers for insights into the competitive landscape.
14. Stop holding onto unfunded projects and send them back.
15. End discrimination against behavioral skills and social sciences. Social networks and contextual computing will require training and people with new skills to augment IT skills.
16. Abandon IT’s unbalanced support between the front and back office, which might lead to a “back office CIO” and a “front office CIO.”

While there’s a wealth of debate in that list, I found item 12 interesting when compared to the others highlighted above. How does one balance costs and benefits after killing the system that allocates those costs out? Item 2 contains two obvious fallacies: first, I’m fairly certain that support of the payroll system doesn’t “improve the income statement” (yet who’s willing to propose killing it?) and second, without being able to accurately identify costs of initiatives, how do you calculate an accurate bottom line? Item 6 has the same problem; how do we have a business unit acknowledge their costs if we do not quantify those costs? Item 7 suffers from the same issue as well. I’m all for retiring applications that have outlived their useful life, but without hard numbers on the costs, how do you determine your savings? For item 14, if we’re not charging back for projects, when we have an unfunded project, to whom do we “send them back”?

I’ve saved item 8 for last. I heartily agree that having all IT spending in the CIO’s budget will make it extremely difficult to determine how much of the costs of IT are attributable to the various business units. One way to alleviate this problem might be to have those business units budget for their needs and then have the provider (internal or external) bill them. Of course, that might break down when you kill the system which actually bills the business units. I am at a loss for how someone could put those two items in the same list.

One of the best reasons for charging back IT costs is stated in a January 2007 CIO.com article by Mark J. Denne:

If IT is to be perceived as valuable, it has to have a price. Usage-based chargeback is the best way to build a price-to-value relationship for IT services, and it is one of the cornerstones for running IT as a business within a business. As long as IT has a solid understanding of its operating costs, it can use pricing as a strategic tool for improving alignment with the business by giving executives better understanding and control over IT resources.

McGee’s item 6, acknowledging costs, is insufficient. Having the business units actually bear the cost is key. When the business unit is actually paying for services received, it becomes invested in getting value for its resource usage. Project cost overruns that affect your own bottom line are much more likely to get your attention than when they impact someone else’s budget.

Another advantage is making IT services fungible (within the limits of the enterprise’s architectural standards). Although this may not sound like an advantage at first blush, in the long run it works in the favor of the internal IT organization. It forces that IT organization to become both customer-focused and cognizant of the need to provide demonstrable value. When the business is put in the position of choosing an internal IT provider rather than being forced to use them, then the relationship dynamic changes. Both parties then have a vested interest in working as partners.

But Chuck Darville says chargeback helps him run IT as a business. “We look to see if someone can do IT better, faster and cheaper,” says Darville, technology planning director at Southern Co., a consortium of five power utilities in Atlanta.

…

Southern’s approach is driven largely by IT’s desire to offer market-competitive products and services. IT managers benchmark products against those of third-party vendors to “ensure that our internal IT offerings are the best deal for the company,” Darville says.

For example, the cost and quality of a network service performed internally would be compared with outsourced services available from providers such as AT&T Corp. or Sprint Corp., he says.

(from “The Chargeback Conundrum”, Computerworld 2/14/2005)

What you want to avoid is passing on costs without any sense of control on the part of the user (emphasis added):

Ultimately, chargeback is meant to prod users into changing their behavior. If a chargeback system fails to accomplish that, it’s a failure, no matter how good the accounting is. Chargeback is wearily familiar to Keith Kaczanowski, vice president of process improvement at Brady Corp. of Milwaukee, a manufacturer of signs, labels and associated printing equipment. “If all you do is reshuffle costs within the company, then chargeback probably isn’t worth it,” he says. “But if you think that people will make better decisions by being forced to confront the cost, then there is value.

“We used to charge $X per person per year, but found no one changed any decisions,” concludes Kaczanowski. “Instead, they just grumbled about a perception of low value. So now we don’t charge out at all.” It was, he adds, “pretty much a consensus decision. A lot of our IT expenses turned out to be for enterprisewide activities, servers, WANs and enterprise applications. Taking it back does a better job of matching where the decision is taken to where the costs are.“

(from “Budgeting – Chargeback for Good or Evil”, CIO.com 3/1/2003

McGee’s rationale for ending chargebacks is that they “take an extraordinary amount of effort and expense to charge back what is a small amount of revenue”. However, over a third of his points involve getting a handle on costs so as to manage them more rationally. This would appear to be an argument for improving systems to capture costs rather than eliminating them. Automation, which an IT shop should be familiar with, should reduce the expense. And while it costs money to track expenses, at the end of the day, attempting to run an organization (IT or otherwise) on intuition rather than information may well turn out to be the most expensive option of all.

Evernote (Thanks for the memory)

While it’s a myth that we only use ten percent of our brain, sometimes it feels like I’ve only set aside that much for storing useful information. That’s one of the reasons I’ve come to love Evernote. Architects of all types are expected to have knowledge and experience that is broad and/or deep, depending on their role. Evernote, with the motto “Remember everything” is an invaluable tool to help capture and catalog information, and more importantly, make it available across a range of clients anywhere with internet access.

The heart of Evernote is the ability to create, store, organize and retrieve notes. A note can comprise text (with a rich array of formatting options) and images. Audio and ink notes can be created as well. Notes are stored in notebooks (which can be local-only, synchronized or even shared with other users). Notebooks can be grouped in stacks. Tags are used to organize notes within and across notebooks and provide a quick retrieval mechanism. There’s also the ability to conduct searches, both ad hoc and saved. Displayed notes can be sorted by time created, last update, title, notebook, etc.

Rather than maintaining favorites at home and at work and worrying about keeping them in synch, I’ve been able to grab and tag information (along with a link back to the source page) that is much more easily retrievable. Notes can come from web pages, emails, even screenshots. Once captured and uploaded, notes are available anywhere you can sign into your account. In addition to serving as my personal knowledge base, I’ve found it a handy tool for composing blog posts (the ability to link one note to another makes for a powerful research tool).

Evernote has a software+services architecture, with local repositories synched to a hosted master. It offers native clients for both Windows and OS X as well as a web interface. Plug-ins exist for several browsers and there’s one for Outlook. Mobile devices supported include iPhone, iPad, iPod Touch, Android, Android Tablet, Blackberry, Blackberry Playbook, Windows Phone 7, Palm Pre and Palm Pixi. You can even create notes by emailing an account hosted by Evernote.

Evernote offers both free and paid accounts.  The paid accounts provide more bandwidth per month (1GB vs 60MB) as well as extra premium features.   A wide variety of add-ons, utilities, etc. are available via the Trunk that further extend the service.

Using extension methods for message transformation

There are many reasons to service-enable an application, from providing an integration to supporting new client types (such as mobile apps). If it’s a layered application with a message-based architecture, then the battle is half won. However, there are pitfalls to avoid, such as having the internal message format exposed to external consumers.

Message and data contracts will likely change with each release as new features are added and old ones tweaked to respond to evolving business needs. This works when all the components using those contracts are built and deployed simultaneously. Once that condition no longer applies, then the schema defining messages and payloads for the external consumers must become invariant. The alternative is attempting to coordinate synchronized releases between two or more applications. This is difficult enough with two internal teams, crossing organizational boundaries can make it truly painful.

Having parallel sets of message and data contracts for internal and external consumers (internal and external being relative to the application, not the organization) allows for the internal schema to evolve while the external schema remains static. Another advantage is that the external schema can be tailored to just the functionality to be exposed. The rub is that now you have to take messages and payloads that come into the service in an external format and transform them to the internal format used by the business layer.

An extremely flexible way to handle message transformation is via serialization and XSLT. Unfortunately, to obtain the flexibility, a measure of performance must be traded. If the service operates asynchronously, then that trade-off will most likely be the optimal one. However, synchronous services, particularly those with high traffic, may find the overhead of this method to be too much. For those situations, a code-based translation approach may give the best performance (albeit sacrificing flexibility).

Having chosen a code-based approach to message transformation, the next question is how best to implement it. Common concerns will be avoiding duplication of code and dependency management. At first glance, it would appear to work if you take the internal messages and add constructors that take the external message as a parameter as well as methods that output the external message. This centralizes the translation function to one or two methods that are co-located with the object to be translated to and from. It also introduces a new dependency to each and every assembly using the internal messages (assuming the external messages are reside in their own assembly). Clearly, this is not the manner in which to implement code-based transformation.

One method to avoid both duplicate code and dependency proliferation is to create static methods on classes that reside in an assembly separate from both the internal and external schema. The translation assembly then need only be referenced by the service layer which is the only one needing its services. While this can be done via a utility class (a la System.Convert), a more intuitive route is to set up extension methods. Extension methods are a bit of syntactic sugar added in version 3.0 of the .Net Framework that allow you to create static methods that appear to be instance methods of the type they extend. This provides centralized code without propagating dependencies unnecessarily and has the advantage of a cleaner syntax.

When asked for the time, don’t explain how your watch works

Communication difficulties between the “technical” and “non-technical” are the stuff of legend. A recent article discussing that disconnect identified the issue as a conflict of values:

Because, for me, a technical person, details reveal truth. Broad, sweeping statements are vague and untrustworthy, nothing more than assertions. They need to be deconstructed, clarified, qualified or proved before I believe that they embody any form of truth. Analysis is my chosen method for discovering truth. Big things are broken down into manageable components that are then examined individually. If the parts cohere, then the whole makes sense.

But for her, a nontechnical person, details cloud truth. Broad statements give her a handle on what’s at stake, so she can test the truth of an idea against her internal sense of what’s what. Essentially, she wants to “feel” the truth. Too many details interfere with her ability to process the explanation, thus preventing her from “getting it.”

The author concludes (rightly so) that tailoring the message to the audience is essential. As his counterpart explained:

 If I had offered a high-level answer that focused on one or two key ideas, she would have been much more receptive. She explained that she would have eventually been interested in the details, but only after she had gotten the gist.

It’s instructive, however, to remember that all of us are “technical” or “non-technical” to a some extent depending on the context. I might have found the author’s exposition on the technology to be as fascinating as he did, but at the garage I’d share the business person’s reaction if faced by an in-depth exposition on my vehicle’s transmission.

It’s also import to examine the second part of that statement: “She explained that she would have eventually been interested in the details, but only after she had gotten the gist.”. The need for shaping the message is never an excuse to withhold information. Professional ethics requires that any caveats or issues should still be presented, just in the format that best insures the message is understood.

All levels of architectural practice will involve communicating with diverse audiences. Taking the time to understand the needs of those audiences will serve to increase your effectiveness.

Like it or not, you have an architecture (in fact, you may have several)

What better way to inaugurate the blog than by defining what is meant by architecture and why you should care?

Wikipedia’s definition: “Architecture is both the process and product of planning, designing and construction” is both concise and comprehensive (which is commendable from an architectural standpoint). It applies to all the various types of architecture, both physical and virtual. Regardless of the size of your organization, you will have multiple “products of planning, designing and construction”.

If you have a laptop, a cable modem and a wireless router, then you have a network architecture. Add in Office, QuickBooks and Gmail and you now have a solutions architecture (with a cloud component, no less). Of course, the data from those applications provides you with an information architecture. Combining those elements with the structure of your business: defining your current state, assessing how well you the technology/data/applications align with the business, mapping out where you want to be etc. and you have an enterprise architecture.

Does this mean that all enterprises, regardless of size, need formal architecture programs and, of course, the architects to run them? Obviously, the answer is “no”. There are far too many successful businesses without such programs for that to be the case. Even if the answer were “yes”, those too small to afford the expense would have to choose between making do and giving up (and I doubt the latter is really an option).

The important thing to take away is that “architect” is the name of a role, not necessarily a position. Not everyone “doing architecture” is a full time architect. Many small business owners perform the functions without thinking of themselves as enterprise architects. What is necessary is that some care is directed toward architectural concerns, because there is a critical omission in the definition above: Architecture should be both the process and product of planning, designing and construction, although it may just be the product of construction.

With one notable exception, most do not intentionally create architectural nightmares. They just evolve that way. You start simple, with an add-on here and an enhancement there; suddenly what was once simple is now rambling and incoherent. In such a situation, maintaining normal function may well consume more and more precious time and attention. This is where an up front focus on architecture pays dividends. Managed growth and change is far easier to deal with (not to mention cheaper) than the organic variety.