Agile Enterprise Architecture

David West, Espalier and Agility

2011-03-04T16:26:00.000-08:00

I like to re-read this presentation Dave West gave back in 2001, once a year. This paper contains a whole bunch of great material about complexity science, Dorsai, how software development IS reality construction, espalier and how Greece vs. Rome is relevant to software engineering.

There's also a nice slide comparing the Agile Manifesto and Extreme Programming, useful for a client presentation. In case you don't want to read the deck:

Agile says: we value individuals and interactions over processes and tools. XP says: put the individuals together and have them work this way.
Agile says: we value working software over comprehensive documentation. XP says: write software the first day and every day, test the first day and every day, refactor the first day and every day.
Agile says: We value customer collaboration over contract negotiation. XP says: Sit the customer down with the programmers and have them steer the project every single day.
Agile says: We value responding to change over following a plan. XP says: Set up intense and rapid feedback and govern yourselves by it.
The fact is, XP's real viewpoint is so radical that it can't even be properly expressed by comparing with those wimpy weightless Agile preferences.

Espalier is one of the concepts Dave mentions in the presentation and the photo is a physical example of hedge espalier at Heronswood Gardens.

Yoda and Architecture

2011-03-04T15:58:00.000-08:00

Quoting a friend of mine impersonating Yoda on the nature of architecture:

"An architect a designer is.
A designer an architect is not."

While I thought I understood it at first, it really took some time plus spending more time with both to really understand the difference. From what I have observed (and practiced myself), designers are really focused on form plus function whereas architects are focused on intended use and managing complexity. That's what I have found to be different about the two roles.

The photo is of a Washington, DC Metro station, perhaps the Union Station stop if I recall correctly.

Agile Anti-Patterns

2010-10-25T12:52:00.000-07:00

I was re-reading The Screwtape Letters: Letters from a Senior to a Junior Devil and it provided the inspiration for a different way of presenting some of agile anti-patterns I have observed over the years. Instead of droning on about what not to do and what to avoid, I think a more active voice would be a little more entertaining and perhaps make the anti-pattern a lot easier to recognize in the real world. The next handful of posts will feature some of the very effective anti-patterns I have seen.

This photo was taken at Deception Falls State Park in Washington, last spring. The winter run-off from the snow-packs was still pretty fierce and some of the overflow from the river made it onto the trail. Plenty of erosion was taking place and struck me as a good way to illustrate how anti-patterns effect projects.

The First Expense To Cut Is Powerpoint

2010-06-10T14:51:00.000-07:00

Yet another company in crisis is finding how much of a time-waster powerpoint is. Via Bob Sutton's blog, an article in the financial times about powerpoint at GM. I just love point #5. Are you really interested in saving time and money? Remove powerpoint from your PCs.

Agile Sunset?

2010-03-26T08:49:00.001-07:00

Based only on my own observations, I think capital-A Agile is on the wane. When mega-consultancies have Agile practices, it's pretty clear that Agile is mainstream, in whatever extraordinarily diluted form it may take. We are now in the long tail of the Agile hype-cycle where Agile has almost become a mandatory label on any project management or software development process. Long live "Agile - * ".

I think a lot of useful lessons (that will actually stick) have come out of this extreme pendulum swing, though. Many have realized that waterfall is just a death-march but, they have also realized there is no Agile Faerie Dust, either. Plus, there is not one methodology to rule them all.

Agile principles certainly have an ongoing role to play but, there is no single recipe. Realizing that may be the biggest benefit of all.

(This is a photo I took of a sunset at Bellingham Bay, several years ago.)

Rice Bowls Full of Data

2009-11-20T08:15:00.000-08:00

It's certainly been a while since I last posted something but, that's what happens when life and work get really busy. I've been trying to shoe-horn an Enterprise Information Management framework (MIKE 2.0) into a Command and Control (C2) environment. It's certainly been a challenge.

The first challenge I had to face was trying to convince a group of entities that there is a difference between information and data. More importantly, that information is more important than data; data management is a subset of information management, not the other way around. That position almost got me lynched. Some time last century when I was actually paying attention in an middle school science class, I learned that information was synthesized/derived from data and was easily interpreted by humans. Then in highschool, it became pretty obvious in that first computer science class that information needed to be decomposed into data so it could be manipulated and stored in a computer.

Simple, huh?

Apparently not.

As with most enterprise architectural conundrums, the problem was neither hardware or software, it was wetware. I dared move the rice-bowl of a 40-year-old empire that only cared for data and cared little about why. When dealing with this group, one observation that I made is that specialization impedes innovation. It may foster optimization but, there is just no room for travel outside of the pidgeon hole.

Security: Show Me The Code

2008-11-13T09:35:00.000-08:00

This seems to be a recurring theme, lately. I'm one of a team of dozens working on a large project and we have a handful of "security professionals" assigned to the team. We have just finished writing a design document and the security section is just huge; directly proportional to the number of people working on it. Anyhow, a bit of stage setting is necessary. I'm participating in a conference call, we have webex running and a collaborative whiteboard plus document sharing.

Me: "This is a big section on security but, it's not complete."

Security Professional: "Oh, what's missing?"

Me: "Software security."

Security Professional: "What do you mean, there's a whole section on how to configure each part of the software stack!"

Me: "No, I meant the software itself, especially the custom software that will need to be developed."

Security Professional: "As long as it's configured properly ... blah blah blah"

I cut/paste a snippet of code for a SQL injection attack onto the whiteboard.

Me: "How do you detect and prevent this?"

Security Professional: "What's that?"

Me: "Code for a SQL injection attack."

Security Professional: "Oh, I don't know anything about that type of security."

Me: "Security isn't a black box."

After that, I let the silence speak for itself. I recommended that as a start, they visit John Viega's outstanding contribution to the security community and re-visit their section of the document.

Money Saving Tip #1

2008-11-11T11:24:00.000-08:00

The only beneficiaries of creating a model of the as-is enterprise architecture are the consultants you hired to create it! Please note, I'm an enterprise architecture consultant.

I was on a sales call the other day and we were chatting with our prospective customer about IT strategy and they wanted some help defining and describing their strategy and lots of help with enterprise architecture. When I asked them where they were in the process, they replied that they were just starting to document the as-is architecture and were following the classic path of as-is, to-be, gap-analysis, etc. and wanted to know how we could help them out. I replied that they needed to choose one of two answers, either the consultant-as-staff-augmentation or the consultant-as-adviser model. When asked what the difference was, I replied "Several hundred thousand dollars."

Naturally, they wanted the less expensive option and I stated if that were really what they were interested in, why do they want to start the process with the as-is architecture? Instead, they could save a truckload of money by starting with what everybody wants to know, the to-be architecture.

You could have heard a pin drop if if were not for the furious typing of the sales rep sending me some rather unflattering IMs questioning my sanity, legitimacy, etc.

"You mean we should not take a comprehensive approach?" asked the CIO.

"Let me put it this way," I replied, "when you go on vacation do you start with a complete survey, inventory and appraisal of your house?"

"Of course not," replied the CIO, "but you didn't answer my question."

"Well, you actually asked 3 questions," I countered. "First, start with your target and then work backwards. Second, only go into as much detail as necessary to make substantial progress. Third, this is unlike most other approaches but unlike others, it won't have the same high chance of failure."

"Thank-you very much, you have given us a lot to think about," was his response.

Much to the shock and surprise of the sales rep, we have been invited to attend some in-depth discussions with several other team members and stakeholders. I anticipate having a discussion about tools, approaches, etc. that will look a lot like this thread in the Enterprise Architecture Network.

Once again, that money saving tip is: "The only beneficiaries of creating a model of the as-is enterprise architecture are the consultants you hired to create it!"

Process vs. Product Quality

2008-10-13T15:04:00.000-07:00

I just finished having a short, hallway conversation with some of my colleagues and it's worth sharing. I was on my soapbox about process quality vs. product quality and I recalled one of the other places I have worked at. It was a matrix organization with a CMMI Level 5 rating, however, we only had a marginally better project success rate than the industry average. I recalled this to my colleagues and asserted that even back at a previous employer, we were CMMI Level 5 because we always made the same mistakes, consistently. Even better, no matter which people we swapped into or out of the process, we still made the same mistakes.

It's perfectly feasible to have a high-quality, consistent GIGO process. Where's the value in that?

IV&V

2008-09-26T00:15:00.000-07:00

I had an opportunity to meet with Mike Rollings of the Burton Group the other day and had a very interesting conversation, touching lightly on several topics.

Regarding enterprise architecture maturity models, he agreed that every model that is currently available is either wholly or largely process-centric and in most cases is not what customers want. They want a quality-based, more tangible maturity model. As a consultant, when I get asked to perform an architectural analysis, the questions my customers inevitably want answered include what's working (and how well), what's broken (and how badly), what can I salvage, what can I exploit, what do I toss, what can I buy, what do I have to build?

Regarding enterprise architecture frameworks in general, he noted a distinct lack of pragmatism in many of them. He agreed that the various framework stewards, including the Open Group, are confusing comprehensiveness for consumability. I wondered aloud if the current frameworks are really being shaped by the (in)ability of the current suite of vendors to implement various, pragmatic facets.

Without answering my question about frameworks, he commented on the almost ubiquitous frustration most enterprise architects have with the existing tools. I'll take that as a diplomatically indirect answer. My major complaints about existing tools are threefold. First, they don't allow complete round-trip visibility from business idea to production. Second, they fall apart when trying to model systems-of-systems. Third, they are built for the needs of modelers, not the needs of the end-customers who need to understand the models. Hmm, just like most of the EA frameworks. Notice the link?

I wanted to chat about business processes, security and the malleability of architectural models but, we ran out of time. It's always good to get some independent validation and verification of one's sanity from a fellow practitioner. Hopefully, we can continue this conversation in the near future.

Security Professionals and Software

2008-09-22T09:35:00.000-07:00

James McGovern simply confirmed what I have observed all along:

I then asked, how many of them actually had a software development background and pretty much every single hand in the room dropped.

This is why we, who do have a software development background, pretty much discount just about everything "security professionals" say. Not only are the overwhelming majority of "security professionals" ignorant of software development and actual code, they seem to be intimidated by anything that's not sold in a black box that they can push buttons on.

Instead of focusing on what not to do, perhaps they should start focusing on how to do something securely. And at the very least, learn enough SQL so a properly parametrized query can be illustrated on a whiteboard.

I have yet to come across a "security professional" I can't send packing after speaking 3, simple words: "Show me code."

TDD and Meaningful Requirements

2008-08-11T11:37:00.000-07:00

Both Craig Brown and Richard Puttick were kind enough to comment on my previous post about meaningful requirements. The post is an extension of a conversation I was a part of with Robert Martin several years ago about Test-Driven Development. The group quickly concluded that unit tests were essentially executable specifications, provided that things like boundary conditions, known negatives, etc. were also fully tested. By extension, user acceptance testing (UAT) were effectively executable requirements, provided that they were tested with the same comprehensiveness as unit tests should be conducted.

Going just one step further, it should be pretty clear that in UAT, not only can the functional expectations be specified in terms of tests and measured against the results, the operational expectations can also be specified in terms of tests and measured against results. These functional and operational expectations are nothing more than functional and technical requirements, both of which can be tested at the same time. This also leads to practice of combining functional and technical requirements into the same statement, which also aids traceability.

We have needlessly complicated our lives and increased opportunities for defect injection by separating functional and technical requirements. A demonstrated good practice, TDD, clearly illustrates how the separation of functional and technical requirements are not only a worst practice, it's not necessary at all.

Enterprise Architecture Maturity Models

2008-08-06T13:34:00.000-07:00

There must be some kind of thread about maturity models crossing the LCD panels of enterprise architects this week. I was again asked for an EA maturity model. I reflexively reached for a couple of the already published maturity models, stopped myself, and asked the question, "EA the noun or EA the verb?"

Apparently, the customer would like an assessment of the maturity of their enterprise architecture, the noun.

This is actually more of a challenge since almost all of the maturity models out there are process-oriented, not product oriented. CMMi is a perfect example. CMMi is product and quality agnostic. GIGO. It's completely possible to build CMMi Level 5 compliant lead-lined lifejackets. The same goes for just about any other process-based maturity model. Not very helpful when the only thing that really counts is the quality of the results, a fact most process weenies seem to forget (or overlook because that's really hard work). Of course, almost all of the EA maturity models (NASICO, Open Group, EAMMF, etc.) are either direct adaptations of CMMi or embed a lot of CMMi in them.

I was pleasantly surprised to find the E2AMM. It didn't surprise me that it's out of Europe at all. The Europeans are so far ahead of the Americas (both continents) in terms of EA it's almost embarassing. No, it is embarassing. Anyhow, I'm going to take a close look at this model to see if it is applicable to this particular customer's needs. I'll post my observations here, later.

SOA Governance and Vendors

2008-08-04T13:23:00.000-07:00

We have seen a bit more consolidation in the SOA components arena again, with Iona and BEA getting swallowed up. I didn't use the term "products" because as we all know, it's not possible to go out and buy a SOA, in spite of all the vendors would have you believe and many corporations and agencies hope for so they can spend year-end cash.

Of course, the same goes for SOA governance, which can't be bought, which Michael Stamback reminds us of. Well, he reminds us of that in his first tip. As for the other 4, let's just see ...

Tip #2: Look for a vendor that can explain how their technology is applied

Ah, and I had such high hopes. At least he could have waited until the 4th or 5th tip to steamroll his own advice. He must be pretty new at this schtick.

Tip #3: Beware of the kitchen sink!

This is great advice from a vendor who just loves to sell the kitchen sink. They re-sell Systinet's (wait, Mercury's .. wait, HP's) product last time I looked. You will probably be better off talking to HP directly and get the story from the horse's mouth. Then again, in terms of SOA components, they now have 2 kitchen sinks to sell, though the home-grown one really never worked and BEA never had any SOA components related to governance.

Tip #4: Start small and expand

Can't argue with that one. Governance tools beyond a whiteboard, post-its and a spreadsheet aren't necessary until you have about a dozen services and at least one is composite. Until then, there's really no SOA; barely a collection of services, really. Then again, who's to argue with someone willing to throw money away?

Tip #5: Look for an integrated solution

Ah, I just love this one. Even back when I participated in an evaluation of all the various governance "solutions" out there, only 2 vendors had an integrated stack (Amberpoint and SOA Software) and only one had a comprehensive run-time offering (SOA Software). I don't see how the landscape has changed, at all. The others may claim to have an "integrated" offering. Well, if a colloid is considered integrated, that's fine.

Of course, none of these folks go down deeper into the stack and deal with how to create, manage and enforce governance policies for the rest of the SOA stack outside of the service, like the service container itself! Then again, that's a really hard problem to solve and of course, you can't sell what you don't have a solution for, right?

Meaningful Requirements

2008-08-01T08:59:00.000-07:00

I simply have to comment on James McGovern's latest post on requirements where he says:

When will we acknowledge that implementation are little decisions made all over and that requirements documentation only decide certain aspects?

This is the result of failing to realize that "technical requirements" cannot be made separate from functional requirements since a function includes the notion of acceptable/predictable behavior. This is where the analysts can borrow a technique from developers: Test-Driven Development (TDD). For lack of a better term, let's call it Test-Driven Analysis.

What would TDA include? It would include a description of the function plus sample inputs, outputs and expected results, including expected failures (samples of say, SQL injection attack code that must be rejected). Moreover, this wouldn't just be data-focused. Other properties such as the range of acceptable response times, expected feedback, etc. need to be determined. Now we have embedded those "technical requirements" directly into the functional requirements plus have added measurable quality attributes that further serve as acceptance tests/criteria.

It's not like this can't be done, it's just a lot of hard work.

Paint Yourself Into The Corner pattern

2008-06-04T10:10:00.000-07:00

Here's how it works. Typically, a new CTO or CIO gets hired/promoted and after a couple of days declares that, "We are now an 'X' technology/platform shop."

I'm going to start calling this the Paint Yourself Into The Corner pattern. You read it here, first. This is similar to the "Fire, Ready, Aim" pattern. It starts out with a CTO (or CIO) declaring that a certain technology or platform is the new standard before understanding what all of the problems are. This decision is usually made on the alleged cost savings to be achieve through standardization, alleged efficiencies to be achieved by having similarly skilled staff in a matrix organization and is largely based on the CTO/CIOs own past skill set (familiarity). Sound stupid? Well, it is. However, why do I see it happening all the time? I've seen people put more thought into what kind of car they want to buy than the time they spend figuring out what types of technology are best for their business.

Enterprise, or any other kind of "technical" architecture is not all about technology. CTOs in particular often forget this. Architecture is about devising manageable solutions that will actually get used to solve specific business problems. It's not about "simplifying" the toolset to make the tools more manageable! Some of these solutions will be very complex but, complexity can be managed. Managing complexity can also be applied to the toolbox.

Tired of The Same Old CRUD?

2008-06-03T08:31:00.000-07:00

One of our customers has a very large robotic storage system and we have been asked to propose a new control system. This meant I needed to do some research and dust off some very old skills. I have always seen robots and software agents as cousins. As I was doing some research, a few patterns started to emerge ...

The first time I had a chance to program (virtual) robots was back on an Apple II with a game called Robot Wars. That may seem pretty humorous but, it taught some difficult lessons: real-time systems, event queues, interrupts, and programming on vastly resource-constrained systems. The developer only had 256 lines of code in which to build their virtual robot. Little did I know at the time this was actually a reasonable training ground for learning how to write embedded systems.

Then, several years later after the PC was invented, Crobots was released, that opened up some more possibilities but robots were still limited to 1000 instructions. There were legions of budding developers and engineers at campuses around the world designing virtual battle-bots.

C++robots broke that 1000 instruction barrier, 10 years later. I don't know much about the evolution of the Crobot genealogy because by the time C++robots came along, I had picked up this new language called Java.

Since we just love re-inventing the ~~wheel~~ robot in this industry, a decade after Crobots some Java devs at IBM were helpint to create Robocode as a way to teach the Java programming language. This turned out to be extremely popular and even spawned international robot leagues. Robocode grew to be very sophisticated, very quickly, including technologies such as swarm intelligence, blackboards and even genetic algorithms. This is very similar to the types of technologies being embedded into software agents for tasks like remote monitoring and supply-chain optimization.

In what appears to be more deja vu, Microsoft has recently released RoboChamps featuring their Concurrency and Coordination Runtime plus the Decentralized Software Services. Why is this important, you ask? Well, most importantly, it's a way to learn about concurrency and distributed systems without killing anybody! Mistakes are safely made in the virtual arena. It also shows a degree of maturity in the .Net platform if it can now be used to solve some of the more difficult computing problems out there.

Anyhow, back to the patterns. Aside from the obvious (4 virtual robot games), I delved into the bios of the authors of RoboCode and RoboChamps. The source of the patterns quickly emerged. All of the authors have substantial and impressive backgrounds in distributed systems, autonomic computing, software factories and a bit of AI. What are some of the major patterns here?

1) Programming robots is a fun way to learn a new programming language
2) Robotics is hard work compared to a web-app
3) Robots have contracts and SLAs with their operating envioronments
4) Robots are autonomous
5) Robots can be employed in co-ordination with other robots to perform more complex functions (loosely-coupled, composition, aggregated processes)
6) Robots can work in parallel (linear scalability)
7) Robots are to a large degree, event-driven

Hmm ... this smells a lot like a service in a SOA, doesn't it?

"Getting" the Business Means "Get In" the Business

2008-04-24T16:18:00.001-07:00

It's always fun visiting the customers at their own workplaces. What takes an hour to describe can instantly be seen; the proverbial picture that's worth a thousand words. I was out at a customer site last week and noticed a very depressing ritual that I have seen many times before. Here's how it goes ...

The consultants are brought in to solve a problem;
The business users are excited that, finally, something is going to get done to fix the problem;
The problem is discussed, a couple of quick suggestions and concepts are described and the business users are enthusiastic about the possibilities;
The business users ask, "So, what are the next steps?"
The IT manager says, "Well, we need to gather the requirements."
The business users physically roll their eyes and slump back in their seats in anticipation of another snail-paced, IT boondoggle.

Here is a very, very important lesson every technology consultant needs to be mindful of: The biggest barrier to your success as a consultant is the technology organization you are there to help/support/augment.

This isn't about folks in IT not having ever learned how to read a balance sheet or other such easily learned knowledge. This also isn't about understanding the basics about how their employer actually makes money and who the customers are. This is about being able to put yourself into the shoes of the people who actually use and need the products and services you provide/build. This is remarkably easy to do.

The key to "getting" the business is to "get in" the business. In this particular case, I had spent a significant chunk of the day on the factory floor observing how people actually accomplished their tasks, complete with impediments, workarounds, frustrations and pride. No requirements document would ever be able to describe the environment and conditions under which the tasks needed to be completed. They would only describe what the user interface was supposed to do. Hopefully I will return in a few weeks where I will resume gathering requirements from the factory floor.

That's right, turn off your computer, put down your whiteboard markers, leave that sterile ivory tower and get onto the floor or out into the field!

Sale or Adoption

2008-04-02T13:58:00.000-07:00

James McGovern talks about failing to sell A/agile in the enterprise. While close, I believe the sales process is not at fault, rather, it's that path to adoption. Also, along with everything else, it's all truly about alignment with the business goals and strategies.

I've recently had the benefit of seeing the life-cycle of almost a dozen agile software development projects over the past year, some ranging through multi-year efforts. I have seen the victories, the failures and the in-between. I started noting some contradictory behavior between customer needs and agile practices, especially the more dogmatic ones. However, I didn't have sufficient data to make any good correlations.

One particular incident involved Test-Driven Development (TDD). In this case the dogma stated that TDD must be done. However, it was truly placing the delivery schedule in jeopardy. Moreover, the deliverables only needed to be good enough. Needless to say, a large rift developed dividing the dogmatics and the customer. Thankfully, the customer's needs prevailed and TDD was tossed and the product was barely delivered in time. This is only one such incident but, clearly the whole concept wasn't working as advertised.

A couple of weeks ago, I stumbled across this paper about software process adoptions. 7 years ago, someone has already thought through this. Bringing back the TDD example, trying to apply a technique that emphasizes quality when the real strategy is innovation (where customers willingly trade quality for newness!) is completely counterproductive. That is, avoid prescriptive processes that require discipline when quality is not the business strategy. Clearly, no matter how hard we try to sell agile, we will fail. Why? There is no logical path for adoption.

Don't sell agile!

To quote a colleague, "Nobody buys Toyota trucks because of the TPS and lean manufacturing."

Technical Requirements

2008-04-02T13:40:00.000-07:00

Simon Brown was kind enough to comment on my previous post and said,

"I'm trying to tackle the other (easier?) problem of when technical people don't even think about NFRs. First things first, we need technical people to understand why NFRs are important."

There's a very simple way to get technical people to understand why technical requirements are important. They must be clearly and logically linked to delivering a functional requirement. Go one step further and simply remove the distinction between functional requirements and technical requirements by stating how a functional requirement must be delivered in terms of quality-of-service or a service level agreement. An example:

"The customer must be able to securely submit the final order plus payment details and receive an acknowledgment via both email and a following web page in under 10 seconds."

Separating technical and functional requirements makes it all too easy to make the former into an afterthought.

Non-functional means it doesn't work!

2008-03-21T09:00:00.000-07:00

Architects are usually quite pre-occupied with ensuring that architectural guidelines and requirements are adhered to during development yet, always struggle to justify them. One of the many attempts made by architects to provide these guidelines is the software architecture document. Simon Brown blogs about another attempt that is probably doomed. Just looking at the document structure, the non-functional view is 4-5 times larger than the functional view.

What does the customer think non-functional requirements mean? No, it's not just semantics. I vividly recall an RFP-response drafting session I was a part of, many years ago. This was the first time I had participated in a fairly large team responding to a multi-billion dollar opportunity. I had finished up one sub-section, and handed it over to my boss. Without raising his head, he took the doc and with his red pen, crossed out every single instance of "non-functional" and handed back the draft to me and said, "The customer doesn't want to pay for something that doesn't work."

Of course, in geek-speak, functional and non-functional have a very specific meaning. In standard, workaday English, functional means something works and non-functional means something doesn't work or is broken. Why then, do we architects pay so much attention to designing software that doesn't work?

If we want all of those architectural "ilities" to be accounted for and truly guide the design/construction of systems, we need to immediately start doing 2 things:

1) Start calling them technical requirements and/or constraints.
2) Directly map them to functional requirements by defining the operational characteristics the customer wants each feature to provide.

Every, single functional requirement should explicitly be able to describe just how much of each "ility" needs to be built, thereby preventing over/under-engineering. This embeds the success measurement criteria for every, single feature!

Maybe we need to start talking about measurement driven requirements (MDR)?

SOA Is Not Enterprise Architecture

2008-03-14T09:31:00.000-07:00

Yet one more person is writing about people talking/writing about the equivalence of SOA and enterprise architecture.

A SOA is one of many possible implementations of an Enterprise Architecture. SOA is not enterprise architecture. More often than not, a SOA will need to co-exist with other architectures in a more comprehensive enterprise architecture.

Sorry boys and girls, EA just isn't that easy.

No BDUF != NoDUF

2008-01-22T14:08:00.000-08:00

Continuing with the theme of architecture in an agile organization, one of the most abused principles in agile software development is that of avoiding Big Design Up Front (BDUF).

No BDUF does not mean NoDUF!

NoBDUF != NoDUF

I submit that every single one of us is guilty of designing a solution to a problem before the person is finished describing what the problem is! Anybody with a modicum of imagination does design up front (DUF). In my experience, the amount of ceremony required for DUF is directly proportional to the cost-to-fix/cost-of-failure. This is pretty obvious in the construction of physical objects, and the debt is tangible. I don't think it's unreasonable to apply the same rule of thumb to software or virtual objects.

Architecture In An Agile Organization

2008-01-18T14:26:00.000-08:00

Last night, my colleague Chris Sterling gave a presentation about Architecture In An Agile Organization. He raised several points I want to develop over the next few posts.

One of the most abused principles in agile software development is that of avoiding Big Design Up Front (BDUF). No BDUF does not mean NoDUF!

Architects are usually quite pre-occupied with ensuring that architectural guidelines and requirements are adhered to during development yet, always struggle to justify them. What does the customer think non-functional requirements mean? No, it's not just semantics.

Architecture is not all about technology. I'm going to start calling this the Paint Yourself Into The Corner pattern. You read it here, first.

Requirements are not specifications. Seriously, there is a difference!

Re-cycle the box

2008-01-16T13:48:00.000-08:00

I was in a meeting with a client a while back along with several other consultants from different companies. Once again, the client was having a problem with their databases (of course!). They had several of each: SQL Server, DB2 and Oracle.

I'm rapidly forming the opinion that any consultant who concentrates on Oracle is nothing more than a corporate shill for Oracle. It seems that almost every solution they have to a database problem is to add another database, thereby increasing license fees for the client. Is there some grand, kick-back scheme or something that Oracle consultants get looped into? At least the people representing IBM and Microsoft product lines suggested investigating other solutions ranging from ETL software to messaging to web services. The Oracle guys went right for the throat and declared that yet another intermediate "consolidation" database instance was the answer. What a crock.

I looked across the table at the CIO and said, "If you are truly serious about solving your integration problem, get rid of one of your database platforms. Let them all know that the two who work together best get to stay." I also reminded him that the company owned all the tools they needed to solve the problem so, capital costs should be 0. I'm not sure if he is going to follow that strategy over the long term but, I certainly know that my suggestion kick-started some very, very creative and resourceful thinking amongst the other 3 groups of consultants!

Which Conference?

2007-10-05T11:01:00.000-07:00

I'm in the process of creating my budget for 2008 and I was hoping to solicit some advice and opinions from my readers. I essentially have 2 questions:

1) Aside from the obvious opportunities for socializing, is attending an Enterprise Architecture conference valuable?

2) If it is valuable, which one to attend?

What I'm looking for is a conference with good case studies, in-the-trenches anecdotes and enough visionaries to give me some idea of what I'll be up against over the next 5 years. A good balance of business and technology would also be good.

Wasn't There A Commercial About This?

2007-06-20T13:35:00.000-07:00

As a customer, I was so impressed with the quality of their work, I joined their company!

Departing my previous employer certainly wasn't an act of prescience, since the undercurrents of certain trends always rise to the top in public companies, it's just that the public is the last to know. From my own perspective, my work there was just one more experience that further convinces me that the practice of enterprise architecture needs to be completely divorced from the IT function in order to be effective. Moreover, enterprise architecture must be seamlessly integrated with a mature, portfolio management practice in order to provide the business stakeholders with the degree of insight and transparency it needs in order to make timely and accurate business decisions.

Anyhow, I now have the opportunity to not only help make this enterprise agile through architecture but, I can help others through leading by example.

Un-Open Open-Door Policy

2007-05-24T13:53:00.000-07:00

Have you ever noticed how corporate-speak can completely rot a manager's mind when they start to believe their own words? The oxymorons and contradictions just start to grow as fast as kudzu. One of my colleagues recently met with his new manager and hastily scribbled down the following quote:

"I have an open-door policy ... but just because my door is open doesn't mean it's OK to come in and talk to me. Schedule an appointment, first."

Of course, this same manager's calendar is always blacked out as "busy" throughout the whole day. It's like the fellow just switches on the "auto-cliche" mode when he walks into the door in the morning. Worse yet, he only has 6 direct reports and he has aspirations of injecting some agility into the SDLC. Clearly a classic example of management-by-in-flight-magazine (mbifm) or hamburger management.

Enterprise-Speed Blogging

2007-05-21T10:35:00.000-07:00

About 1.5 years ago, a tiny group of ~~dissidents~~ visionaries (the victorious get to re-write history) established a stealth wiki and also started using it's blogging capabilities. This was only the first. Exactly a half-dozen of us have been continuously blogging, internally. Apparently it was a shock to some internal auditors, lawyers, HR and senior execs when they had the ~~original~~ idea of setting up an internal, corporate blog, that one already existed. To their credit, they didn't shut down the stealth blogs.

Anyhow, the point of the post is that it took the enterprise about 1 year from idea to roll-out. Aside from the obvious conclusion that most enterprises are as agile as a cow on skates, the fact that it took people in the enterprise a year to overcome FUD, find/allocate resources and devise a management scheme for a non-revenue-generating internal resource. All this for a simple piece of blogging software that I'm sure any of my readers could have set up and running in an afternoon. That's all the time it took us to set up the original wiki and blog, too. Getting the installation officially blessed took the other 364.5 days.

Proponents of open-source software, Ruby and other dynamic languages, methodologies, etc. need to take into account it takes time to overcome FUD even in light of working proof.

Architectural Role & Career Progression

2007-05-18T11:01:00.000-07:00

Simon Brown has started an interesting discussion about career paths for architects. To code or not to code is one of the thoughts, as is the timing of architecture transitioning from being technology-oriented to business-oriented. Business-Oriented Architecture (BOA), anyone?

Reasons Why IT Sucks

2007-05-17T10:31:00.000-07:00

I was enjoying reading through Neil Hepburn's post about SOA without IT governance until I came across this:

"If you're going to switch to building things using a SOA approach, you're probably just going to start building services for new applications. Those applications in turn will be funded by projects, which will be managed by a project managers' whose responsibilities are to the success of the project, and not for the success of IT infrastructure. As the PMI likes to remind us: "Never goldplate". Full disclosure: I am PMI certified. Okay, so what does this mean? This means that while it is possible to build re-usable services. In all likelihood, they will be built for a specific application."

In this case, IT governance is being used to treat or prevent a symptom - redundancy. The underlying cause has been completely glossed over. An application is the wrong level of abstraction for a SOA. Regardless of how hard we try, applications are incredibly static. Business demands flexible logic and processes which we have wrapped up in very inflexible applications.

Instead, the creation of services needs to be driven by the business domain model. There should be no duplication of behavior and data in the business domain model and that becomes the spring-board for service development. Domain models are surprisingly resilient. They also don't change much over time in an industry. The business is all about how that domain model is used. Each service is a publicly accessible implementation of a domain object (remember what an object is: behavior and data). The application is reduced to the (often) ad-hoc collection of rules and sequences that bind a collection of services together to form a business process.

IT sucks because we focus on how the domain objects and logic are packaged as an entity. After all, we can box up, shrink-wrap and sell entities. We focus on building-to-last instead of building-to-change.

SOA Economics

2007-05-12T15:26:00.000-07:00

I was going to add this as a comment to Alastair's recent post about SOA The Economics of Agility but, I wanted to expand on my comment. I think he has unearthed a very interesting point. When the up-front costs of setting up a SOA properly are examined, it's not that different from the same up-front costs the telcos faced when they first started building their networks almost a century ago. A huge infrastructure was required to be put in place well before the last mile could actually be delivered (switches, hubs, cables, directories, sub-stations, human routers, etc.). Maybe we should look to how cellular/wireless telecom has flourished in places recently where there was no classic telco infrastructure in place. There was certainly a master plan for deployment and management but, installation was incremental and flexible. Surely if deployments for entire countries can be logically designed and planned, we ought to be able to do the same in an enterprise.

A SOA without at least a registry and repository quickly devolves from a small collection of services to a P2P mess. Once a P2P network reaches a certain size, it basically becomes unmanageable. However, P2P networks flourish because they are so easy and cheap to set up. It's the classic pay-me-now or pay-me-later argument. If we can find the line between keeping the agility of a P2P network vs. the cost-effective management capabilities of a SOA for a particular organization, the move to a full-fledged SOA not only makes economic sense, it makes obvious sense. The problem is, there's no recipe; however, it's not a mystery, either. That's how the wireless carriers grew, right?

IT Literate or Business Illiterate

2007-05-11T14:40:00.000-07:00

Andy Mulholland asks, "What is the role of an IT department when the users are IT literate?" That's certainly a valid question but, it's not nearly as threatening as the current, widening gap between business and IT. The question we still don't have an answer to is, "What is the role of the IT department when its employees are business illiterate?" Have we just just decided to keep living with the status quo and hope for that magic day when the users are IT literate? I guess that's really not a problem for most of the CIOs and pundits because they will be long retired when that day comes so, it will be somebody else's problem.

Should Architects Code?

2007-05-09T16:12:00.000-07:00

If a picture is worth a thousand words, one concrete example is worth a thousand abstractions. I have to attribute inspiration for the previous sentence to Jack Greenfield when I heard him talk about software factories. One of the observations he has made about design patterns is that they are great at describing how but poor at describing when. This leads nicely into the topic of whether or not architects should code. Let's take a look at a couple of situations.

Should architects write production code? That's probably not a very effective use of their time and skills. One of the hardest parts of becoming an architect is to realize that coding is no longer the primary job. A transition needs to be made from being the one who is concerned with building something right to being the one who makes sure the right thing is built. However, one of the jobs of an architect is to show others how to build something right so, be ready to dig-in and pair-program with someone on the team so that knowledge and experience is passed on.

Getting back to Jack Greenfield, one of the topics he has written about is that developers that are either junior or new to a team lack context. They need to learn the domain, patterns to solve problems in that domain and finally, when to use those patterns. One way to accelerate this is to provide worked examples? Again, templates are great but, they are only as useful as patterns. Knowing when to use a design pattern within a domain is the kind of knowledge and context and architect needs to supply. Provide worked examples, not templates.

One of the other duties of an architect is innovation. Not only is keeping current important, keeping in touch with what the next big thing might be is just as important. Testing new products, evaluating frameworks and just trying out new ideas all need hands-on time. Often, who else has the time to innovate? When it comes time to talk to people about a new idea, get feedback and even sell the idea, that's when a page or two of some clearly written examples are worth a thousand powerpoint slides.

If architects don't code, are they still architects? Sure but, perhaps not as effective as they could be.

How To Think About The Agile Enterprise

2007-05-08T17:31:00.000-07:00

It seems that the technology marketing buzzword factories have been hard at work, because a bit of web research reveals a whole slurry of terms:

Adaptive Enterprise
Agile Enterprise
Business On-Demand
Real-Time Enterprise
Zero-Latency Enterprise

The contrarian in me smells snake oil. It seems that whenever the IT industry gets it's hands on a concept, there ends up being way too many solutions to solve very few problems. When consultants sell methodologies and vendors sell products that claim to provide an agile enterprise, that's a pretty good indicator of the difficulty of the goal. If it's truly that easy, how come more companies aren't agile?

Let's do ourselves a big favor and completely forget about technology, methodologies and processes. Frankly, I think these three things are actually impediments to agility as they are most commonly understood and applied. They are actually all related.

The biggest impediment to agility is inertia. Most enterprises are about as agile as a supertanker. Actually, that's not quite accurate. Ships have freedom of movement, it's just that the movement can be very slow. It's possible to be slow and agile. Most enterprises are as agile as freight trains. That's more accurate. Trains have lots of inertia and they travel along defined paths; there are no steering wheels in locomotives. However, large companies can be steered in different directions, albeit slowly. Most enterprises are as agile as a cow on skates. Not only does it not want to be on skates, once moving, it does not want to change direction for fear of crashing. Aside from the comic value, that's a pretty useful description.

The second is data-centric thinking. For those of you who have never worked in a large organization, making a change to a database or data model is almost impossible. There are legions of people dedicated to protecting the sanctity of the schema and are human-shields to change. We love static, permanent structures. This mindset is a major part of the problem; agile database is an oxymoron. The fact is that data is useless without interpretation. Just look at any database table with several columns of foreign keys to see what I mean; without interpretation (joins), the data in the table is meaningless. The whole goal of normal-form analysis is to maximize the use of joins, thereby rendering raw data even more meaningless. In most cases, agility requires changes in use and interpretation, not the data structure.

The third is our fondness of ceteris paribus models. We like nice, sequential, step-by-step models where only one variable changes at a time. Those models are great for teaching/learning but are useless for operations. It's impossible to run even a lemonade stand with ceteris paribus models. We need to have models that help manage dynamic, multi-variable systems that are often non-sequential.

We build systems using the second and third concepts even though we know they are no longer working well and we consistently apply the first concept in the face of external forces. Going forward, we talk about loose-coupling, re-use and process management, etc. Aren't all of those just more, simple models re-cast into agile roles (and just as likely to fail)? Perhaps, that's all the vendors are selling because that's all they can build?

Instead of loose-coupling (which still implies assembly), perhaps we need to think in terms of mixtures, aggregates and ad-hoc federations?

Instead of processes, maybe we should focus on events and variability management?

Instead of re-use and general purpose, one-size-fits-all components, possibly the focus should be on more multi-purpose components that can be easily adapted within a more limited domain?

Maybe the core problem is that we think of an agile enterprise in terms of what we already have built or know how to build? Maybe the answer is to truly understand what needs to be built and not recapitulate solutions?

Too Much Abstraction Or Ineffective Perspective?

2007-05-04T08:53:00.000-07:00

The Pragmatic Architect writes about The Neverending Abstraction. My knee-jerk reaction is that abstraction is perfectly valid when contained within the domain of the problem but, doesn't need to be expanded to deal with every possible case outside of that domain. In other words, don't over-engineer the solution.

Then I started thinking about the possible root-cause of this common behavior. Perhaps it's not the layers of abstraction that are the problem but, instead it's the depth of the taxonomy. What happens when a Vendor becomes a Customer? What happens when a key person at one customer, who has a deep history with your company, changes jobs? As much as we hate to admit it, very few of us practice true OO because we have had deep taxonomies and Nth normal form drilled into us since elementary school (kingdom, phylum, genus, species, etc.). The result of this is that we cast the majority of our objects solely as data containers, not interactive (behavior-based) information sources. This has two side-effects. The first steers us towards designing class hierarchies based on attributes, not behavior. The second is that our objects are too big. Let's look at the Customer object in The Neverending Abstraction.

This is a situation many of us have encountered, where the object is a Customer and it contains a field called name. Let's think about this a bit. How many different ways are you asked about information concerning your name? How many different ways do you ask your customers about information concerning their name?

first name
last name
middle initial(s)
middle name(s)
christian name(s)
full name
surname
generation
title
salutation
prefix
suffix
first four letters of your surname
nickname

That's at least 14 methods, not including possible formats (last name first, etc.). Doesn't that constitute it's own object? When a Name needs to be applied to a company, it's easy to add common name, legal name, d.b.a, etc. Now, on to the Customer object. You are a customer of many companies or, are you? We tend to define ourselves by what we do. However, we do many things. Does that imply we have a clone for each major task we do? Of course not, we are a Person object that happens to be performing a specific Role. That should guide our thinking about OO abstractions.

The second possible root-cause is computer science education. Even when introductory courses are taught with an OO language, the first thing that we learn (in the case of Java) are the primitives and the second are control structures. We still haven't shed a half-century of procedural baggage. I can sum this up with one, very simple (American-centric) example. Hands up, how many people have used (in Java) an int for a zipcode? How would you address a package destined for Portland, Maine?

Try abstracting behavior, first. Then, worry about the attributes. Isn't the mantra, "Program to interfaces?"

H1-B vs. Off-shoring

2007-05-02T14:48:00.000-07:00

Why do we need to increase the pool of H1-B visas? Since cheap talent/labor is the goal, why not just move the work off-shore? Or, is the pent-up demand for H1-B visas a tacit admission that having bodies in-house is far preferable to off-shoring for a number of reasons?

Dr. Frederick Young has another insight about H1-B visas expressed in U.S. Students Discouraged:

"Those who want to increase the number of foreign workers are looking for cheap labor and aren't helping our national security. If they want more good IT professionals, let them pay better wages!"

SOA Governance and Vendor Consolidation

2007-04-30T15:26:00.000-07:00

About a year ago, it seemed that getting the old brain around SOA governance was a lot easier. There were plenty of vendors in the space, not so much hype and vendors could truly distinguish themselves through creative use of buzzwords. After so many mergers and even one nested acquisition(!), the proliferation of buzzwords around SOA governance has ceased and it's now become very difficult to evaluate products. I don't know how the big analyst shops manage to stay up to date. I just hope I can make it through an initial evaluation before there is one buzzword to rule them all, effectively making it meaningless ... at which point I hope to have something in place before those who manage-by-magazine read the buzzword and want the latest, shiny bauble.

I wonder if the job title "Marketing Engineer" actually exists? I bet each vendors' ministry of truth has a few on the payroll.

Widening Gap Between Business and IT

2007-04-27T07:10:00.000-07:00

Alastair comments on an earlier post where I wrote about software skills and development skills. This prompts me to take a closer look at what I wrote based on what I see happening in many companies. I certainly read a lot about the necessity to align IT with the business but, I really don't see that happening. I actually think there is an increasing amount of mis-alignment. One major symptom which I believe proves this is outsourcing.

Setting aside all of the buzzwords about efficiency, core competencies, etc., outsourcing is about saving money and reducing payroll size. Everything else is pretty much bullshit. The root cause of outsourcing being so attractive up front really comes down to 2 issues:

a) Low quality requirements;
b) A mutual lack of respect and understanding between business and tech.

In a typical business/IT arrangement, the first thing that happens on any project is the kickoff meeting followed by 1 person from IT meeting with about 1/10 of the people in the kickoff meeting for several weeks-months, gathering requirements. Based on past experience with waterfall-like development and the length of time required, the business thinks, "If I don't get all of my feature requests in that requirements doc, I'll never get it done." At the end of the process is a comprehensive requirements document, forming the basis of a contract between business and IT. Then, the spec gets handed off to development (an intra-company gap) and the business sees nothing until the first demo/beta.

In a typical outsourcing arrangement, the first thing that happens on any project is an army of experts like analysts, designers and architects from the outsourcing company show up, typically outnumbering the client's staff by 3:1. Why does this happen? Simply, this is the outsourcer's insurance policy; clear, detailed requirements form the basis of the contract for delivery. Based on their experience, the outsourcer knows that businesspeople generally can't write requirements and that discovering requirements is a highly labor-intensive business. There's lots of data stating that the largest costs in any development project are gathering requirements and fixing defective software due to defective requirements. Therefore, it's in the outsourcer's best interest to make sure the requirements doc is as comprehensive as possible. Then, the spec gets handed off to development (a wider, inter-company gap) and the business sees nothing until the first demo/beta.

Look at the similarities! The goal is comprehensiveness, not quality or priority. When the goal is quantity, cheap labor will win, every time. Isn't it easier to see why outsourcing looks so much more attractive, up front? The business sees that due to the cost of labor differences, it will take less time/money to develop a comprehensive contract, or, given equal time the outsourcer can develop a far more comprehensive contract.

How can we solve this problem in favor of business needs and in-house IT? That brings me to my second issue, the mutual lack of respect and understanding between business and tech. The formal solution would be to train businesspeople how to discover and write better requirements and also train IT staff how to better elicit requirements. The less formal (and zero-cost) solution would be to co-locate (no gap) the developers with the business people. This would allow the developers to deeply understand the intent behind the requirement and it would allow the business to focus on the most important requirements at that moment. Sounds a lot like the techniques favored by agile software development methodologies.

It would seem that a relatively simple change in the physical business architecture would reduce both software development costs and legal costs (for when the outsourcer doesn't deliver what was intended for them to deliver).

How To Scale RoR

2007-04-25T11:42:00.000-07:00

I attended one of Sun's executive briefings yesterday and I saw the ideal way to scale any one of the database-driven web development stacks:

http://www.sun.com/servers/x64/x4500/specs.xml

Now that solid-state disks are becoming more reasonably priced, replacing a bank of spindles with solid-state drives acting as an advanced disk cache, that should solve any database latency problems. As long as shared-nothing is practiced in the application layer, this could solve the scaling issue.

2 Views of Agile Enterprise Architecture

2007-04-23T15:19:00.000-07:00

Most of the EA implementations I have seen (and worked on) involve a tremendous amount of navel-gazing (aka Current State Analysis) followed by a lot of BDUF and BMUF. The resulting documents are usually out of date by the time the initial draft has been blessed by all the reviewers and any of the technical merit in the document reads more like it was generated by the marketing departments of the selected vendors than by the EA team.

When I took the time to read the comment and change request logs for the document, it was pretty easy to see what parts of the document were actually useful to people (lots of comments, complaints) vs. those that simply could have been omitted, entirely. In one case, a 1200 page mini-series could have been condensed into a podcast. Perhaps at it's simplest, this might be a way of practicing Agile Enterprise Architecture, at least in a manner comprehensible by the framework-followers. The most useful sections of the document were:

Diagrams explaining the business processes and which systems supported them
Diagrams showing the logical systems, their inter-relationships and data flow
Catalog of physical and software assets
Catalog of capabilities and services (for both staff and software)
A long-term technology procurement plan and evaluation process
Worked examples, not templates

These were the 6 artifacts that the majority of the people in the organization actually found useful, regardless of occupation. What about the future state, you ask? That's the most interesting part. Aside from the execs who liked the large, color plotter posters on the walls and in their offices, only the architects, planners and vendors cared. The rest of the organization only cared about the next phase on the road map. When I walked around the IT organization, the diagram that I saw pinned to most walls was the migration and transition plan from the current year to next year. Think about that for a moment. Furthermore, the meat of that diagram indicated development of new systems that had already been approved plus new paths for systems consolidation identified during the EA exercise. My take-away from this was that the majority of the really useful information could have been published months before the end-state, big-picture was complete. In that case, we missed the boat on practicing Agile Enterprise Architecture.

Now that I'm a bit older and perhaps wiser, I look back at the work I have done and wonder if it was truly valuable? I have never been a big believer of wasting time doing current-state analysis. In my opinion, all of that information and documentation should already exist throughout the organization. What should really happen in the first phase on an EA exercise is to corral all of the existing operations manuals. I know, I'm dreaming but, I digress. Anyhow to answer my own question, I think the value of the exercise was dubious. All we really did was record the tribal knowledge and set forth some common sense guidelines. That's more like Enterprise Archaeology, and there's nothing agile about that! I suppose there was some short-term value but, certainly little that is lasting.

So, as an enterprise architect, what can I do that is valuable? As I stated before, I don't believe that bringing agility to enterprise architecture is very valuable. Necessary, but not valuable. Perhaps a subtle re-statement is all that is needed? When I actually keep my mouth shut and listen to what the people on the business side of the company are actually saying, I hear a lot of words and phrases like process changes, new regulations, nimble, waivers, exceptions, changing market conditions, adaptable product lines, etc. What they really want, in terms of assets I can create, is an Agile Enterprise Architecture. The value of an agile enterprise in tomorrow's business conditions, is obvious, don't you agree?

How To Evaluate ESBs

2007-04-19T16:25:00.000-07:00

I was asked how we evaluated ESBs when we did our tests, last year. We used Brenda Michelson's paper from Seybold as our springboard. It provided both use cases for our POC tests and feature categories for our survey. The download is free (after registration).

Ideas 5 Years Ahead of Their Time

2007-04-12T09:37:00.000-07:00

I received an email message the other day asking me if I wasn't being too arrogant by stating my ideas are 5 years ahead of their time. Reviewing the work I have done over the years, 5 years is a good average. Please remember I state this timeline based on the behavior of large organizations. These are places where products and services don't get released, they escape. Here is a typical timeline for an idea:

Year 1

look ahead to see the list of potential risks and problems the business will run into
find interesting research or immature but innovative product that will solve some business problems
squeeze in time during day job to throw together a quick prototype
analyze prototype findings to death
if successful, put together a demo and a business case to get funding for a POC
sell

Year 2

look ahead and see risks and business problems get bigger
listen to really smart exec (singular!) who see the same problems and beg them for POC funds
perform POC on a low-priority track so work starts and stops for months
perhaps finish POC and analyze findings to death
revise business case with more accurate financials and develop a plan for a pilot project
sell

Year 3

look ahead and see risks and business problems starting to effect business operations
listen to really smart and smart execs (plural but, usually not several) who see the same problems beginning to effect operations and beg them for funds/staff for a pilot
perform pilot project on a low-priority track so work starts and stops for months
pilot gets cancelled because all resources must now be focused on fixing some of the more serious problems the pilot could fix
listen to execs whine and panic about the risks and problems
form committee to find solution
committee recommends a solution amazingly similar to the pilot
sell

Year 4

risks and problems have become a crisis
listen to customers complaining about the risks and business problems
listen to scared execs screaming "we don't have time to do a pilot, we need to fix this now!"
launch large scale project to fix problems and remove risks
find consultants
start fixing problem
write specs
fail and don't renew consultant's contracts
fall on sword

Year 5

listen to CEO talk about the strategic importance of the pilot/mega-project
take lessons learned, re-scope and re-prioritize pilot/mega-project
re-name and re-launch pilot/mega-project
maybe re-evaluate solutions
put lower priority projects on hold (see Year 3)
form core team of employees and have a clear vision
re-start pilot/mega-project
find consultants
fix problems and remove risks
roll-out the solution into production

The cycle time varies but in my experience, I have never seen this happen any faster than 2 years and I have heard of similar projects stretching out to almost 7 years. And those numbers are for the projects that actually make it past Year 4; about 70% of ideas don't. In companies that use a waterfall SDLC, this will also be the timeline for almost every idea, regardless of size.

I'm not claiming any kind of prescience or precognition, only the knowledge that in order to set up the game that identifies and fixes a problem in a year (a reasonable amount of time), the set-up time is close to 4 years! Therefore, the original idea for the implemented solution needs to be about 5 years ahead of its time.

Carr, Citi and IT spending

2007-04-11T15:43:00.000-07:00

Nicholas Carr is certainly a great writer but, he's a terrible mathematician. In his latest post, he mentions that Citi is going to cut IT spending by $4.6 billion over the next 3 years or as he states, find "...new opportunities to do more with less."

Nicholas, companies only get to do less with less. Given two activities and money for one, there are only two choices: do both activities half-baked or, fund only one. I actually think spending cuts like this are a good thing because it's basically the last ditch effort to force the business to make up it's mind about what features it can't live without and which ones are gravy. Wouldn't that be nice? We all know that IT spending is, to a large part, based on the business forecasts for growth and demand, and we all know how accurate those are!

On the other hand, we in IT really don't help the business make those hard decisions. We want to be nice and say yes to everything. Worse, we often say yes to the wrong thing. Just this morning I was in a meeting where we were evaluating options based on feature groups, and which features were most important. When I actually shut my mouth and really heard what the customer was saying, both their number one fear and number one need were not addressed by any of the requirements, directly. I brought this up which resulted in stunned silence. We re-arranged the spreadsheet and after a couple of minutes worth of back-of-the-envelope calculations, two of the six options just dropped off the map and a third is in serious jeopardy. Option number one isn't looking too credible, either.

Deliver what the IT customer needs, not what they want; a subtle difference with huge implications.

StoryTestIQ - STIQ

2007-04-10T09:10:00.000-07:00

My friend, Chris Sterling over at SolutionsIQ, reminded me of the value of executable requirements when we last spoke about dealing with outsourced development. James McGovern writes far more eloquently about the successes and benefits of outsourcing than I can so, I'll avoid that discussion here. Outsourcing is a reality I have to live with so, I need to develop some mitigation strategies. Having well-defined user acceptance tests in the form of executable requirements is one strategy I'm trying to get embedded at work. Some time ago, he posted a message in the Scrum Development mailing list about STIQ and it's intended use:

I will preface my email with the fact that I am one of the developers for StoryTestIQ (aka STIQ) and that we use it on many projects currently at SolutionsIQ. We created STIQ out of a need to help our Product Owner describe what they were asking for in their feature requests and ultimately user stories. STIQ is a combination of Fit, FitNesse, and Selenium with some special sauce that allows you to do both web UI and beneath the UI acceptance testing.

Here is a scenario of how we use it:

Upon completion of the Sprint Planning Meeting we come out with the following artifacts related to the development of our acceptance tests:

* User Stories the team has committed to

* Acceptance Criteria (aka "Confirmation" from Ron Jeffries description of a user story)

* Some high level communications about the user interactions which have been formally or informally captured

Our teams immediately go to work on created automated Acceptance Tests using this information and further collaboration with the Product Owner and other Subject Matter Experts (SME). After we have built up a good amount of Acceptance Tests for our applications we will collect a bunch of utility scripts which get us to specific parts of the application or do repetitive things like login as multiple types of users. Usually we can put together some scaffolding for our Acceptance Tests rather quickly using these utility scripts and much of the collaboration happens after this.

After setting up our Acceptance Tests we will "tag" them with the name of the Sprint so that we can create a test suite which represents all Acceptance Tests for the Sprint. All of the individual tests which are collected into this test suite should be failing to begin with because we have added in the expectations of the User Story's Acceptance Criteria into the tests. Once a user story has tests ready (meaning failing tests created with acceptance of the tests from our Product Owner) then we begin coding using TDD and potentially creating more QA regression tests which go beyond the Acceptance Tests. These extra tests may go into a different tool (such JMeter, QTP, DBUnit, xUnit, etc...) or could be extra tests added to STIQ.

Once the team has developed all of the artifacts needed to meet their Definition of Done and the Acceptance Tests are all passing for a User Story then the User Story is "accepted" with validation from the Product Owner during the Sprint hopefully. We get feedback on a continual basis through a Continuous Integration tool that we use with STIQ to show if all Acceptance Tests are passing that have been included into the build (meaning the development has been worked through to make that test "pass").

We are not perfect in the creation of all Acceptance Tests at the beginning of the Sprint with the Product Owner, SME, business analysts, etc. But we do have a very good start on capturing the intent of the Sprint deliverables. There are many times that development of code to satisfy an Acceptance Test may identify a potential issue which the Product Owner negotiates with the team to resolve. There are also times that the Product Owner, upon seeing the actual working code, may decide to negotiate on specific details of an Acceptance Test. I believe that the tight feedback loops with the Product Owner increases our ability to deliver closer to what the customer wants without as much rework.

I hope this helps and would be interested in what and how you decide to move forward with Acceptance Testing mostly in the automated capacity. In full disclosure it is not an easy practice to work into your daily routines. There are many bumps and bruises along the way but once it starts to settle out things get a whole lot better. I know for myself that I do not like creating software in any other way.

I have a notion that my biggest obstacle will be laziness. After all, it's just so much easier to write down the requirements in a Word doc than it is to really think about what is needed and how to prove success from the outset.

Another Reason Why Enterprises Don't Like Dynamic Languages

2007-04-09T07:59:00.000-07:00

Again, I'm trying to get a handful of our developers to look at different approaches and languages to develop applications. We have many, internal applications that the customer never sees but, still get used by thousands of employees all the time throughout the day. Recently, we identified a new series of apps we need to build and instead of using a heavyweight framework plus Java, I suggested something a lot more lightweight and more suited to rapid development since these applications don't need to be engineered to the same tolerances as our customer-facing applications do. Again, I have to bring up scalability.

When I need to run applications in crowded, power-constrained data centers, every CPU cycle counts. Supporting thousands of simultaneous users takes a lot of boxes, even more so when I have to consider performance numbers like these. Ruby zealots should be particularly embarrassed; the language has been out almost as long as Python and that's the best it can do? And as for Smalltalk, at least make a middle-aged language go as fast as that other middle-aged language: Lisp. I'd even be more confident recommending Smalltalk if it were as zippy as C# Mono. Sure, we enterprisey types are the target of a lot of cheap shots (and even get a rare chance to take one) but, when a new data center costs $25 million to build and we have to consider the cost of power in KWhs where pennies make a big difference, feature development time becomes irrelevant vs. the year-over-year operating cost of those apps on a large scale.

When I try to take a stand and be a voice for change in the face of hundreds (literally!) of C++ and Java developers who have a need for speed, benchmark results like the ones at the end of the URL, above, don't help my case at all. It pretty much gets me and your favorite language laughed right out of the room. Add to that the the typical software developers' stubborn and irrational resistance against trying something new, and the battle is pretty much lost from the start. It's actually very frustrating and discouraging.

Addendum: Many thanks to "keith" for showing me the way to ST/X which, after reading the docs, looks to be exactly what I'm looking for with regards to performance.

How To Accurately Estimate Projects

2007-04-08T09:13:00.000-07:00

Back in the 1940's, the Rand Corporation described a methodology to accurately estimate just about anything for any project. The technique is called Delphi and it was enhanced in the 1970's and was re-named to Wideband Delphi after Barry Boehm added some refinements. There is an excellent article at embedded.com that describes the technique. It's worthwhile reading before going on to my next paragraph.

I really get a kick out of the hard core PMBOK crowd when they tell me that agile techniques are fine for small projects but don't scale to large ones. Frankly, I just have to look at some of the MS-Project monstrosities I wonder how scalable those are. Wideband Delphi has been used to accurately estimate some pretty large, expensive and life-critical projects. After reading the article, for anyone with even with a bit of familiarity with most agile techniques, one sentence in the article should really stand out:

"Do some architectural design, bring a group of experts together, have them estimate individually, and then use a defined process to make the estimates converge to a common meeting point."

That's really not much different than "elaborate and understand the user stories, have the team individually estimate story sizes and iterate through negotiations to reach an agreed upon size for the story." That's pretty much what happens in an XP or Scrum iteration, isn't it? That's certainly the approach I have used. Let's take a closer look at the Wideband Delphi and Scrum to see where Scrum has corresponding steps.

Delphi: Assemble a team of 3-7 experts and a moderator.
Scrum: Assemble a team of no more than7-9 including a scrum master.

Delphi: Coordinator presents each expert with a specification and an estimation form.
Scrum: Scrum master presents the stories.

Delphi: Coordinator calls a group meeting in which the experts discuss estimation issues with the coordinator and each other.
Scrum: Scrum master calls a planning meeting with the team and product owner to clarify the stories.

Delphi: Experts fill out forms anonymously.
Scrum: Team members individual estimate each story's size.

Delphi: Coordinator prepares and distributes a summary of the estimates.
Scrum: Scrum master puts stories and corresponding sizes on the wall.

Delphi: Coordinator calls a group meeting, specifically focusing on having the experts discuss points where their estimates vary widely
Scrum: Scrum master allows everyone to explain their story sizes, one story at a time.

Delphi: Experts fill out forms, again anonymously, and steps 4 to 6 are iterated for as many rounds as appropriate.
Scrum: Scrum master facilitates a negotiation between team members to come to a resolution of a story size, one story at a time until all stories are sized.

I just find it interesting that a proven technique gets revived about 50 years later to be codified into agile methodologies. It's also interesting to see that expertise and experience are valued as the key ingredients for accurate estimates above all other methods. Too bad PMBOK doesn't include a "History of Project Management" that goes back 100 years; I think fewer projects would fail if project managers actually repeated the useful parts of history, like recalling that people are always more accurate than (MS) Project.

Ivory Tower or Crow's Nest?

2007-04-04T10:35:00.000-07:00

Yes, it is true that architects, especially us enterprisey types, often get accused of being ivory tower academics. I will admit, at least in my case, that is sometimes true although that is certainly not my intent. However, I while I try hard to not work in the tower, I just spend time thinking in it. There's nothing wrong with a little bit of professional dissociation from a problem. In fact, it often aids objectivity. One thing a tower does provide me with is a very different perspective and a much longer horizon. That perspective allows me to think and plan ahead or, even see a way out of the maze. When lost in the middle of Mirkwood, the best thing to do is climb a tall tree to get some reference bearings.

When we were kids, how often would we remark that people looked like ants when we were looking down on them from a tall building or even an aircraft? Of course, it would be nice if large groups of people would be as well organized and cooperative as ants instead of being a meandering herd but, that's another post. To continue, some might even call this top down perspective the "big picture" or "the reason why" for the situation at hand. From a bit of a distance, it is easier to see all the interactions, the real scope, shortcuts, dead ends, pitfalls and approaching problems. Those are all benefits of retreating into the tower. Naturally the main drawback to retreating into the tower is that (most) towers are static. The second is that they are difficult to build or tear down. Both of those drawbacks are contrary to the principle of agility.

Is there such a thing as an agile ivory tower and is there a need for one? I think so, as long as a few key requirements are met, including:

the benefit must be visible
its occupants must be in step with the rest of the team
staying in it too long is uncomfortable
there is a direct communication and feedback loop

That's why I like the idea of a crow's nest or lookout. It provides the benefits of a tower but it's also strictly utilitarian. Now, if we could only convince businesses of the value of having a lookout place high enough to see beyond the next quarter ....

How To Evaluate Open Source Software

2007-04-02T10:11:00.000-07:00

The Business Readiness Rating is a proposed as a "framework for evaluating open source software."

Now that's what I've been talking about!! I would encourage my fellow architects and open source developers to get involved so that what is important to you becomes a guideline for evaluating your own software. I'll be sending an email message to getinvolved@openbrr.org as soon as I finish writing this entry.

Applied IT vs. Computer Science/Technology

2007-03-27T17:57:00.000-07:00

I wonder if one of the root causes of the ever widening gap between the Business and IT are the business schools?

During another vendor demo, two of the presentations specifically covered business processes with workflow definitions along with business rules. Mid-way during the presentation, one of the audience asked, "These tools are typically used by someone from IT, right?"

Without missing a beat, the vendor said, "No, this should be really familiar to anyone who has used Visio to diagram a workflow and the rule definer should be very familiar to anyone who has used Excel macros." Needless to say, that went over like a led zeppelin and the room fell silent. "Don't you have business analysts," asked the vendor? "They are usually the people who do this but, at most of our deployments, the end-users in the business write and test their own rules. Sometimes, they might have the help of a very junior IT person if the logic is particularly complex or chained, though."

Again, more awkward silence. I interjected with, "We actually don't have a job classification of business analyst here but, these responsibilities would probably fall into the domain of a program manager or an operations analyst," whereupon all of the program managers glared at me. As an aside, most of the program managers work in IT!

Of course, my knee-jerk reaction (which I kept to myself!) was the thought of me having to do my job and part of the businesses' job, too! Taking a mental step back, I really wonder if this is fair? I've worked in many different environments and to a large degree, the one tool almost everyone on the business side can use far more efficiently than I can is Excel. I've seen some pretty amazing and impressive spreadsheet macros in my career. However, perhaps the business-people who are capable of these feats of spreadsheet scripting are just as rare in the business as it is to find a good programmer in an off-shore outsourcing company?

In this age of self-service, why aren't business schools teaching their students to exploit common, desktop technology? Not just use, but really exploit and actually design curriculums to require these tools to be used at progressively complex levels. Instead of making them take a programming course, why not focus on some applied technology courses starting in their freshman year where they need to build some fairly complicated financial models involving multiple cases and decisions? The last time I looked at a B-School curriculum (about 2 years ago), this kind of coursework didn't appear in the calendar until until 3rd or 4th year. Back in the paleolithic age, when I was in school, this level of applied technology was usually relegated to MBA students!

Getting back to the demonstration, I had the impression that most of the spreadsheet users in the room were really skilled with the layout tools in a spreadsheet, maybe even knew how to add columns and do some basic cell manipulations but otherwise, were pretty much dead in the water. Am I off-base? I'm certainly not trying to shift the blame, by any means; I'm just as disappointed at the miserable job the majority of IT has done with respect to delivering value to the business (current employer not excepted) but, I'm sure there is a bit of blame to share.

Gartner or Graft

2007-03-26T22:04:00.001-07:00

I was recently in a presentation by given by a CRM vendor. At the tail end, one of the members of the audience asked about the recent slippage by the vendor out of Gartner's magic quadrant. The reps were candid, yet resigned. They said that there was a corporate decision to stop paying Gartner money and invest marketing funds, otherwise.

Pay Gartner, stay in magic quadrant.
Don't pay Gartner, fall out of magic quadrant.

The reps looked pretty apprehensive so I said, "Don't worry, for those of us who understand exactly how most industry analysts operate, this works in your favor, not against it." To go one step further, the next time a sales rep or marketing droid calls me up and mentions where they are in the magic quadrant, I'll very curtly inform them how little I think of that analysis and what a corresponding waste of money that line item of their marketing budget Gartner payola is.

I have to say that the list of industry analysts and trade publications that I can confidently rely on for information is rapidly dwindling. After the project I am working on is over, I'm going to make a point of working with our CIO to re-visit the funds we allocate to various subscriptions, especially to analyst firms, and make some recommendations.

Enterprise Standard Open Source Software

2007-03-21T21:04:00.000-07:00

Between meetings being held in preparation for a week of on-site vendor demos, I caught up on some blog reading. James McGovern replied to my earlier post which triggered another thought. We have evaluated over 2 dozen vendors, did a first round of literature evaluation against our requirements, did a second round of RFIs against our requirements and have arrived at the short-list for demos, next week. I did work with the main technical stakeholder to determine if there are any open source products that could fill all or part of the solution set. Regrettably, there aren't but, at least we did the investigation. The software suites we are investigating will be used as a company-wide standard and will retire several redundant systems which have all outlived their usefulness.

This lead me to think about our open source software use policy and our procurement process. There are several cost-reduction projects underway and a part of each project is trying to standardize software. Naturally, there aren't perfect solutions for every case so, architecture has decided to adopt a preferred choice and second choice ranking. It occurred to me that one more option was missing. If there happened to be 2 commercial options, there should also be an open-source option, too. I modified the asset catalog to look something like this:

Software Domain	Preferred Commercial	Preferred Open-Source	Alternate Commercial	Alternate Open-Source
Application Server	N/A	Tomcat	WebLogic	JBoss

Changing the asset catalog to this format allows both an open-source option to be considered and an open-source option to be the only option for preferred/alternate, if appropriate. Now, if only the federal government would modify the TRM in the FEAF, we taxpayers might be spared some of the tax burden by forcing agencies to consider open-source options.

Industry Analysis We Really Need

2007-03-19T09:37:00.000-07:00

The kind of industry analyst the IT industry is in dire need of is something like Underwriter's Laboratories or Consumer Reports. People or an organization that do more than a comparative literature review (I can hire interns to do that!) and actually try out/beat up products in a lab. The analyst would have to be vendor-independent so, in other words, can't receive revenue from a vendor for performing a study or doing an evaluation. Software and hardware would be provided to the analyst on an extended-loan period, determined through negotiation between a vendor and the analyst. If the analyst chooses to receive payments for advertising from vendors, that income must be reported publicly and in an obvious location by a dis-interested third-party. Perhaps the analyst might even be able to work out a strategy with it's clientele to provide temporarily-assigned staff dedicated to performing evaluations?

One-Horse Show vs. A 3-Ring Circus

2007-03-16T09:12:00.000-07:00

Either Justin or Stuart blogged about my previous post where I mentioned the need for speed from dynamic languages. I know that for 9/10 web applications, this is true. However, my employer happens to be in that 1/10 category. Regarding my performance requirements, not only do I have to be concerned with throughput and latency, I also need to be concerned with real-time performance. Auctions, markets, exchanges and utilities are all real-time e-commerce business models, some of which deal with perishables. If I was talking about hundreds of requests/second, I could host our apps on PDAs, not blades.

That's why us enterprisey types need to see the landscape a little differently based on the business requirements of our employers. It's a matter of scale. For example, we lose 6-7 figures of gross revenue for every 30 seconds of added latency delivered to the browser. The net of that 30 seconds pays 7 developers' salaries for a year. That kind of money would keep a 2-horse consultancy running for several years, I suspect. In my previous job where I was concerned with the speed of code delivery, a 1 million dollar contract meant I could employ a team of 8 developers for a year. When the scale changes from millions of dollars per year to millions of dollars per minute, that changes the priority of technical requirements. Now, I'm concerned with the speed that code can deliver. At a certain level of deployment for dynamic languages, the efficiency of the VM becomes far more important than the efficiency of the language. Dynamic languages certainly have their place in the enterprise (we use most of them), just not for the majority of our customer-facing applications. Drastically improve the efficiency of the underlying VMs and that picture will change but, not before then.

Why I Can't Take Smalltalk Seriously

2007-03-10T11:12:00.000-08:00

Please notice that I wrote can't, not won't! I'm on the technical advisory board for a startup and they are intent on doing everything the right way. When we started to talk about web frameworks, everything was on the whiteboard for discussion: .Net, JSF, Tapestry, PHP, Ruby/Rails, Django, etc. I also mentioned WebObjects and Seaside. That caused a mix of puzzled looks and laughter. On the upside, the architecture we are proposing will allow them to consider Seaside but, this is the exception to the rule.

Meanwhile, back at my day job, I couldn't consider Seaside. We have billions of dollars worth of data and information stored in SQL Server, Oracle and DB2. That's a big, brick wall to hit. I need tools like JDBC, ODBC, JPA, Hibernate, iBatis, multi-threaded connection pools, drivers for each RDBMS (plus MySQL and Postgres would be nice) etc. Yes, I know there's GLORP but please ...

I also need scalability to tens of thousands of simultaneous users. That's also one of the reasons we can't use Ruby/Rails, either. When we need hundreds of servers to run a single application supporting thousands of users, cost of manageability becomes a very important factor. At this level, programmer productivity really counts for nothing. I'm far more interested in lowest cost of operation rather than cost of development. If it takes a dev a month or two longer to code something robust and manageable in Java or .Net, and the application is going to be in production for years, guess what wins? Just add more hardware is no longer a viable strategy when datacenters have been maxed out for both space and power consumption.

If I'm wrong about some points here, please let me know. Although, I did put some fair effort into researching how Smalltalk could meet some of these requirements but, I guess I was using the wrong keywords. Perhaps the Smalltalk community can help me get Smalltalk into at least one enterprise.

One Reason Why Enterprises Don't Like Dynamic Languages

2007-03-06T09:41:00.000-08:00

I believe one of the major reasons object-oriented dynamic languages like Smalltalk, Python, Ruby aren't widely used in enterprises is really well outlined on page 3 of this article in e-Week:

"But it's just coming into its own where you could defend it to nontechnical people as a language on which you could develop enterprise software. One of the things we have going for us is, because we're founded by computer scientists, we don't have to defend our use of that programming language because it's not Java," Kelley said.
"We have a wonderful ability here to choose the right tool for the job. We have components that are written in Java, in C++, in Python, and Ruby and Perl. [Python is] definitely viewed internally here by some of the best computer scientists in the world, people from MIT's AI [artificial intelligence] and CS [computer science] labs, as enterprise worthy," he said.

Once again, a combination of laziness and CYA win out over the imperative to deliver real business value such as:

... all kinds of productivity and cost benefits, including lower cost of maintenance, better ability to integrate with modern architectures, and the ability to add components and enhancements more easily than with the mainframe, Kelley said.

There is also a great quote about line-coders vs. problem solvers, but I'll leave it up to readers to find that gem. I also have to add that from personal experience, it's a whole lot easier to teach a bunch of mainframe and COBOL programmers Python than it is Java or C#. In fact, it was really just a matter of pointing them in the direction of Python, asking them to use pyUnit and let them run wild. On the other hand, teaching them Java drained tens of thousands of dollars from my operating budget!

A Few Notes On Quality

2007-02-26T21:01:00.000-08:00

James McGovern talks about quality in a recent post. In the shadow of six-sigma, TQM, ISO 9xxx and CMMI, we need to remind ourselves that the pursuit of quality has lead some to the brink of insanity. Perhaps it's the methods we have been cajoled into employing for measuring quality that are insane.

Feigenbaum, Deming and their contemporaries were the first to apply statistical analysis to quality management in the 1930's. In Total Quality Control, Feigenbaum states, “In the phrase ‘quality-control’, the word quality does not have the popular meaning of ‘best’ in any absolute sense. To industry, it means ‘best for certain customer conditions’.” Perfection can be measured because there must be one, ultimate example the desired product. The existence of an exemplar is the basis for six-sigma and all the other quality control methods in industry. However, this poses a bit of a problem for software development.

How so? Well, in most cases the goal of software development is to build a single instance of an exemplar! Using methods designed to measure defects or deviations from an exemplar in order to create that exemplar seems to be a little unrealistic. Does that mean we fall back to "best for certain customer conditions"? Of course, this begs the question, what is quality and how is quality measured?

This very question vexed Robert M. Pirsig so much, that he was eventually incarcerated in a psychiatric facility for a number of years. In his world-famous book, Zen And The Art Of Motorcycle Maintenance: An Inquiry into Values, Pirsig writes, “Quality … you know what it is, yet you don’t know what it is. But that’s self-contradictory. But some things are better than others, that is, they have more quality. But when you try to say what the quality is, apart from the things that have it, it all goes poof! There’s nothing to talk about. But if you can’t say what Quality is, how do you know what it is, or how do you even know that it even exists?” Pirsig’s approach was to establish a stable system. Using one of his college classes as an experiment in quality, he informed his students that he would be withholding letter grades just in their class until the end of the semester. “Then a hoped-for phenomenon began. During the third or fourth week some of the A students began to get nervous and started to turn in superb work and hang around after class with questions that fished for some indication as to how they were doing. The B and high-C students began to notice this and work a little and bring up the quality of their papers to a more usual level. The low C, D and future Fs began to show up for class just to see what was going on.” Pirsig had hoped and predicted that his students knew exactly what quality was and without any measure of their progress whatsoever, would know exactly what they had to do to improve the quality of their work. He then moves into a long dialog about the philosophy of quality and how quality is defined and recognized, however, he does not manage to find how quality can be measured.

I think we all know when a piece of software is crap. Instead of exerting effort devising methods to measure quality, enforce quality, etc., why can't we just spend all that superfluous time and effort preventing problems in the first place and fixing them, when they occur?

Open Source Software Policy

2007-02-12T20:38:00.000-08:00

Earlier, I posted about the open source software policy I developed for my employer. Optaros, Inc. has a similar policy which it has published for the benefit of us all.

Lifecycle or Immortality

2007-02-12T08:47:00.000-08:00

Vilas talks about exceptions to the enterprise architecture as slums. I have to agree. In fact, as EAs, we need to plan for their emergence. Let's face it, people will find ways to work around processes, rules and guidelines if enough money is at stake and frankly, that's the way it should be. Our enterprises exist to make money and aside from regulations, everything that does not support that goal is fluff. There is a large difference between governance and policing and too often, we forget this and start EA practices from the point of enforcement rather than guidance and containment. The best way to manage deviations from the grand plan is to anticipate them by providing a lightweight process for granting architectural waivers.

Let's revisit the SDLC acronym. The last half is Life Cycle. Death is a part of the Life Cycle. Yes, there is an old maxim that says "software lives forever" and there is truth to that; that is also the kind of immortality that needs to be well-defined within an enterprise architecture. Therefore, don't make slums immortal. Give them a lifespan. Why don't we want slums around in the first place? Well, they are difficult to govern and that leads to expensive maintenance. It should be relatively easy to show the long-term maintenance costs for a slum in it's business plan. At some point, the system will either need to be turned off because of TOC or, it needs to be refactored into the EA to lower it's cost of operations.

When designing the process for granting a waiver, ensure that there is a Retire or Re-factor clause in the plan stating either a date the software is to be removed from production or the date re-factoring is to begin. Clever designers will keep the existing EA as a constraint when building the slum so that when it comes time to retire or re-factor, the cost of doing so is as low as possible.

Wishlist Item!!

2007-02-09T16:26:00.000-08:00

Now this is a 16-bit processor I would just love to have!

Latency and Design

2007-02-09T13:58:00.000-08:00

Once again, we are reminded that bandwidth can be bought but latency lives forever. I think that over the past 10 years or so, we have largely ignored this axiom or worse, never really learned the difference. In an attempt to simplify our architectures, we have added layers and have relied on physical deployment to keep the architecture neat and tidy. Separation of concerns were enforced by the wire. Client-server, 3-tier, n-tier, etc. Worse, each box represented one application or sub-component of a single application. This approach has been hawked as a viable pattern for a distributed application. Well, it's not, it's all about distributing an application. There is a difference and yet, we still haven't learned much about how to design and build distributed applications. Why is this an issue? Well, it's not until we start running out of room in the datacenter or we actually want to get the most out of our desk/laptop with a multi-core processor. See where I'm going with this?

Consider a case where we have Photoshop, a 4-core cpu and a very large photo. Which approach is going to get the job done with the least latency:

4 copies of photoshop processing 1 photo each,
4 copies of photoshop, each processing 1/4 of the photo,
1 copy of photoshop sending 1/4 of the task in parallel to each core?

Ok, that's a bit of an unfair question. Let me re-phrase, which approach will have the most latency? If you answered #1, that's most likely. So, why do we continue to build web and enterprise applications like this when time is money? That, by the way, is an entirely fair question and I'm sure your CFO would like to know the answer.

Project Black Box

2007-02-03T19:56:00.000-08:00

While at Sun Labs last week, I had an opportunity to see project Black Box. In a nutshell, the idea is to use a standard 8'x20' ISO standard shipping container, put doors on both ends and re-model the interior turning the container into a portable data center. It's an interesting concept that I'm sure has been knocked about for several years and I recall several companies have created mobile data centers but, this one is a bit different.

The most interesting aspect about the Black Box is the potential compute and storage density. While there are 8 standard 40U racks, 7 are available for customer use. After taking away space for cables, etc, that leaves 7 racks with 38U of space, each. Plus, the racks slide out, sideways, into the central aisle allowing for simultaneous access to the front and rear of the rack from each end of the service aisle. Combined with the well-designed cooling and air circulation system, this is about 30% less floor space than what can be put into a typical data center. Assuming A/C, raised floor, and structure, the savings are even more compelling.

Sun plans to sell the unequipped box for $300-$400K and the servers and storage are extra. The customer needs to supply water, power and network access. It will be interesting to see what kinds of new business concepts the Black Box will enable.

Enterprise Open Source Policy

2007-01-26T13:07:00.000-08:00

One of my colleagues asked me what I had contributed to open-source, lately. I actually haven't contributed any source code to an OSS project for several years but, last year I managed to make a rather rare contribution. I lead a handful of co-workers and we drafted our company's official Open Source Software Use Policy. After a technical, security and legal review, it has become the set of guidelines we use in practice, almost every day. It's probably the most popular standard any EA group I know of has ever written. What follows is a brief synopsis of the policy.

First, we defined several categories of use ranging from just downloading the binary and using the tool all the way to modifying the OSS code and using it on the customer-facing site. Our attorneys were very helpful in this regard as we had to do a risk-benefit analysis from several different viewpoints.

Second, we used the Open Source Initiative's list of licenses and evaluated all of them. We then created a matrix and cross-referenced the license with the category of use. Now this does not mean that just because the license is approved for the category that someone can actually use the software. That's a separate issue.

Third, we outlined a lightweight evaluation process where if the license is approved, the developer and their manager would determine if the software was actually appropriate to use, consult with architecture (something similar might already be pre-approved) and prototype a case. The development manager and the architect can both approve the use of the OSS code in production.

Fourth, we defined a simple process for making contributions back to the OSS community. Simply, development, architecture and legal would review the code and if approved, the company's governing board would be asked to allow the submission back to the project. We essentially piggy-backed on the same process already in place for identifying possible patents and trade secrets, a process most public companies already have.

Fifth, we created the guidelines for a company-sponsored OSS project. This included identifying one senior developer as an ambassador for the project.

We also set policy about extracurricular coding, and weaved that into the employment agreement.

Finally, we also describe a policy where the procurement of OSS software is no different than the procurement of any other software and it gets managed like any other company asset.

The resulting benefits of this policy have been very positive and measurable. We have cataloged all OSS in use, all of it is properly maintained and version-controlled and plenty of patches, bug-fixes and documentation have been submitted to a number of OSS projects. Everybody wins.

I have even personally used the policy as a recruiting tool when asked what the company policy is regarding OSS. It has indeed sealed the deal for several people we have hired.

Horizontal Scalability - See I'm Not Crazy

2007-01-25T19:59:00.000-08:00

When the gents at eBay gave their presentation at SD Forum 2006, it was great timing for me. First, it provided independent working proof for several concepts we were prototyping, thereby verifying we were on the right track and not undertaking some "wild EA research project". Yes, that's a quote. It's also rather gratifiying to know that eBay has in production some of the same technology we had selected for our stack, specifically for operations management. Second, I had published material to counter the cries of the Luddites and other technologists that need to be dragged into the 1990's. Third, it's pretty much confirmed a lot of ideas I had about how to horizontally scale applications. I won't go into the differences between distributing an application vs. a distributed application because that's material for another blog post. However, distributing the data is just as interesting.

Just looking at the data from our critical search paths based on http traffic, it was obvious we needed to horizontally partition our data. The eBay paper provided the data I needed to finally tip the scales and get this project underway. We had long since realized we had to vertically partition data because disk-based RDBMSes have been too slow from day one. This fact has been verified time and time again since we have at least 3 differnent kinds of caches on top of read-only banks of DB servers. This begs the question of why use a cache at all? Are we using it to avoid hitting the database or, are we really using it to get the persisted data as close to the application as possible? The difference between the two viewpoints is critical, as it turns out. We prototyped a way to replace the read-only farms of RDMBSes with something a lot less expensive. We can trade 10 licenses for 2 and re-allocate 60% of the hardware. Over the next couple of weeks, we will prove the concept. This could be very interesting, especially if we can save a couple million on licensing costs, next year.

Transparency Specified

2007-01-23T21:04:00.000-08:00

I was chatting with a colleague today and he's working on a blogging policy for our company. Strangely enough, it's about internal company blogging, which was pretty anti-climactic. There was no mention of either employees blogging to the public or empolyees, on their own time, blogging to the public.

In contrast, I came across an ad today for a Chief Archiect today and one of the requirements included "Contributions in external forums (conferences, publications, blogs, open source)".

CYA Trumps Productivity ... Again

2007-01-08T08:57:00.000-08:00

I'm beginning to wonder if I'm actually an enterprise architect or a portfolio manager. Of course, I can make a very strong argument for portfolio management being a sub-function of enterprise architecture but, that's another post altogether.

I'm leading a small, very senior team through the process of selecting various technologies to become enterprise standards in the general realm of "temporary and persistent data storage". We actually can't say caches and databases because that would unecessarily spook the herd. Anyhow, the problem begins with the fact that this is a very senior team and each one of us has a diverse work history and the correspondingly large t-shirt collections. This enables us to leverage our experience and move through the evaluation process much more quickly. The fact that we have very crisp requirements helps a lot, too. The second aspect of the problem is that we are using SCRUM to manage the project within some fairly short sprints. The work involves research, disposable prototypes and POCs.

Last week, we ran into some problems with regards to progress and status reporting. In the interest of brevity, we decided to condense each finding, outcome and recommendation as a line item for a bullet list. After several iterations of charts, graphs, tables and nested lists, we still had too much information. The granularity of information shrunk from "upgrade database cluster X hardware and add a hardware load balancer" to "upgrade database hardware". After several more iterations, we finally managed to extract the real objections. These are quotes from the review meeting:

"This is too much information for a 2-week reporting period."

"These aren't interim results?"

"You guys are trying to solve world hunger!"

After a bit of questioning, it turns out there are several other teams working on different projects using similar approaches. The main point of contention gradually emerged: this team was completing almost twice the amount of story points as other, larger teams. That meant, the other teams' progress was much easier to track and understand because there were less work products to review.

We were actually told to "increase your transparency" and "adjust your delivery schedule to accomodate the other teams." We were also asked to create a "responsibility traceability matrix"(TM) so we could track the handoff of our findings/recommendations as they were incorporated into projects and finished. Now, there's all kinds of items that can be extracted from between the lines and I agree with most of it. There you have it, folks: Traceability and accountability are more important than productivity, no matter the size of the project or the demands of the business.

Industry Analysts and Conferences

2006-12-17T20:24:00.000-08:00

I stopped going to most industry conferences a long time ago. In the software world, the only ones I bother with are SDWest and the local edition of No Fluff Just Stuff. I also try to get to OOPSLA once in a while. As for the rest, I can get the same information by reading any of the trade magazines. Otherwise, I tend to stick with much more concise workshops or the birds-of-a-feather sessions.

We were going through a budget triage the other day and the "research" line item came up. A discussion about which account we should keep be it Gartner, Burton, etc. I didn't voice an opinion since I think they are all equally poor. Analysts are playing the game at the same table but, they don't have any chips. Win or lose, they still get paid to be at the table. The other disappointing thing about many of the analysts is that they only report on the current state and maybe stick their necks out about a year, or so. Several of the topics analysts are current ranting about, colleagues and I were researching almost a decade ago, made into corporate "secret-sauce" about 5 years ago and have already leveraged all the competitive advantages of the technology, all before it becomes common practice.

Anyhow, back to triage. After a bit of debate, we all pretty much reached the same conclusion and just decided to get a bunch of corporate subscriptions to the ACM and IEEE.

Transparency vs. Productivity

2006-12-14T19:18:00.000-08:00

I was asked to write down my thoughts about transparency vs. productivity in the enterprise. A glib response is that no matter how transparent the process or project, someone will always make the accusation of conspiracy or plead ignorance. Of course, transparency also doesn’t guarantee homogeneous interpretation, either.

In terms of enterprise architecture or just about any other endeavor, it’s always wise to eschew transparency in favor of productivity, especially at the beginning of any task. At least keep the inner workings in the dark until the general idea is developed into a tangible concept that can be tested. This approach can reduce churn, keeps the clarity of the original idea intact yet allows for a fair degree of refinement. Once there is something tangible to share, that’s the time for transparency and as a result, be prepared to reduce the pace of progress by at least 50%!

Companies that are public, in heavily regulated industries or produce life/financially critical systems really don’t care too much about productivity, anymore. This is even more apparent in the shadow of SOX. As soon as any process or product is subject to external or public scrutiny, transparency trumps productivity, every time. This is actually a two-pronged attack on productivity. First, the baggage of transparency is carried by the people who actually get the job done, thereby slowing them down. Second, people who used to be dedicated to getting the job done are now re-purposed into building and maintaining the baggage!

Productivity leads to success, which leads to IPO, which leads to transparency, which leads to lack of productivity. I recall an old military slogan, “Hard work is rewarded with more responsibility and hard work.”

What these larger companies really care about are innovation and lowering total cost of operations.

A Definition of Enterprise Architecture

2006-11-29T20:56:00.000-08:00

Today, I was asked, "What is enterprise architecture?" There should be a simple answer for such a simple question.

The first question that popped into my mind was, “From which point of view?” Of course, the answer to that is from the point of view of someone who knows nothing about architectural views! Some of the definitions I have read seem to blend the role of enterprise architecture with a definition of it.

In the spirit of agility, I propose a single sentence definition:

Enterprise architecture is a set of models describing the technical implementation of business strategy and processes.

Opening Post

2006-11-04T18:07:00.000-08:00

Agile enterprise. That certainly seems like an oxymoron! If that is the case, then agile enterprise architecture must be related. Ambler has already written an essay about agile enterprise architecture but, like most of the material available about enterprise architecture, it is almost completely software-centric and it starts with the technology. Yes, he does say it's all about the people but, everything he discusses is about the technical model and it's multiplicity of views.

I propose that enterprise architecture can be agile, that it can be a tool for the business and not the techs, and that it can be lightweight and useful on almost a daily basis. It should be the technical realization of the business' overall strategy and goals complete with a set of guidelines to aid in the strategy's implementation.

Wish me luck!