Application Platform Strategies Blog

News Flash: Insourcing Fosters Relationship

Blogger: Kirk Knoernschild

A recent article on TechTarget claims that IT insourcing is on the rise. In other words, organizations are beginning to bring their recently outsourced IT functions back in-house. The article cites a few motivating forces for this change. Organizations have more control, can respond more quickly to business change, and are leery of outsourcing going forward due to unpleasant past experiences. The articles cites on of the reasons for outsourcing - it was cheaper - may not actually be true. While outsourcing may be cheaper short-term, the long-term cost may be more. Not an epiphany, for sure.

But what really caught my eye was the following quote from the article:

There's a sense of intimacy with the business users that's hard to achieve with outsourcing.

That's a rather profound statement. It took outsourcing for us to realize that collaboration with business users is a critical success factor on an IT initiative? Wow.

IT Labor

Since we're on the topic of outsourcing.... Another popular reason why organizations outsource is due to the IT labor shortage. Many claim there is a lack of qualified IT candidates. This reason is also the foundation of the H-1B program. Not so fast. I've never actually believed this was entirely true. My good friend Randy once said, "There's also a shortage of $2.00 per six pack micro-brews." If you're interested in IT labor, this Lou Dobb's video might interest you.

Conspiracy Theory

I take my car to a certified GM dealership, even though it's a bit more expensive than going to the hometown mechanic. Why? Because I know they won't use secondhand or refurbished parts. I also know they have the specialized equipment and expertise to work on my model vehicle. But if the GM dealership charged a 50% premium for the same level of service I could get at my local auto shop, I'd have no motivation to take my vehicle to the dealership. Now, apply this analogy to corporate IT.

If corporate IT charges a 50% premium over an outsourcing provider, but doesn't provide any strategic or competitive advantage to the organization, what's the motivation to use corporate IT? Instead, it's sound fiscal strategy to outsource. In other words, why should I pay $100 an hour for crap when I can get the same crap for $75?

For now, let's ignore the crap (that's a topic of discussion for another day), and instead focus on cost. $75 an hour may seem cheaper than $100 an hour, but only when you fail to factor in the number of hours it takes to complete a project. And the challenges inherent to distributed development, contract negotation with outsourcing providers, and more will impact delivery, which will increase time, which will drive up cost. So now, we're starting to realize that outsourcing isn't necessarily cheaper. Don't be surprised to see aggressive legislation on the table soon asking for an increase to the H-1B cap. Wouldn't it be ideal to have the best of both worlds? Cheap labor that's co-located! Really? Is it possible there's a causal relation between IT failure, motivation behind outsourcing, and the H-1B program?

Disclaimer: I'm not claiming that everything we deliver is crap. But there is no shortage of evidence illustrating some of the challenges we've had in delivering IT projects.

Disclaimer: I don't claim that we should abolish the H-1B program. However, there is evidence that H-1B visa holders are paid between $12,500 and $20,000 less than citizens. That's not the purpose of the program.

Increasing Your Agility

Blogger: Kirk Knoernschild

Some remark that agile development processes have crossed they chasm - agile is mainstream and adoption is widespread. I'm not convinced that's true. Instead, I find that waterfall development is still alive and prospering. Unfortunately, the teams leveraging waterfall methods are not prospering. In fact, I'd argue that less than half of all software development teams leverage agile practices. I have no hard data that supports my claim, only anecdotal evidence suggesting it's valid. Regardless, it's disconcerting. Why?

Given today's economic woes, the impetus is on IT to show and prove their value. Continuing with status quo will not suffice. We're being asked to do more with less - fewer resources, shorter timeframes, reduced budgets, and more. While organizations look for ways to reduce costs, IT has been given a window of opportunity. It's critical that we take advantage of it.

So what can should we do? Look at what we can do to improve the quality of the software we deliver. Bake quality into the product from the beginning instead of attempting to validate quality at the end of the lifecycle. Look at what we can do to improve the efficiency of our team. Eliminate practices that aren't directly contributing to customer value. Look at what we can do to improve the transparency of the development effort. Engage the customer and share the good and the bad surrounding the current state of the system. These are just a few of the things we need to be doing now, and each have a direct correlation to reducing cost.

Agile processes and practices can help in these, and many other areas, but only if applied correctly and pragmatically. Adopting Scrum, XP, or any other agile method won't guarantee success. It won't guarantee agility. Agility is not defined by process adoption, but by the ability of the team to deliver valued software in a timely fashion. At this years Catalyst conference, I'll be leading a workshop titled Improving the Software Development Process. In this workshop, I'll be talking about ways to increase agility and improve the development process. Surprisingly, little of the discussion will focus on agile processes. Instead, the discussion focuses on techniques to improve software quality, maximize team efficiency, increase transparency, and more. I argue this is the essence of increased agility; not process adoption. We'll discuss actionable items that teams can use immediately.

If you're attending Catalyst, and are interested in improving your software development process, I encourage you to attend the workshop. If you do not plan to attend Catalyst, but are a Burton Group client, schedule a dialog now and we can discuss the issues, how they interrelate, and what you can be doing now to improve your software development efforts.

Scaling Agile

Blogger: Kirk Knoernschild

There seems to be a common myth that agile practices work well for small teams, but don't scale for large enterprise development efforts. Experience has shown me the opposite.  Certainly agile methods are a natural fit for smaller teams, who don't have the unique communication challenges and project management difficulties present with larger teams. In fact, it's these unique challenges that makes agile practices such a perfect fit for large teams. It's time to debunk the myth that agile practices don't scale.

I've written two pieces recently about using agile practices on big teams. The first talks about a macro process for making the practices work. The second clarifies a few items that may raise questions and cause for concern. I've also created a couple Burton Group resources that can help a team increase their agility. The first is a paper that talks about Rightsizing the Software Development Process, and the second explores Continuous Integration and it's many benefits. There is also other relevant and valuable information in our research library, including Agile Software Development: Not For Lightweights and SDLC Infrastructure: Supporting the Development Process.

This material underscores some fundamental elements that explain why agile practices are so important for any team. Strive to always have a functional system. Leverage the functional system to increase collaboration and garner important feedback from the customer. The more feedback you can get earlier in the development lifecycle, the better you'll know whether you're on track to deliver a system the customer values. As customer feedback and collaboration increase, so to does project transparency. Everyone - the development team and the customer team - understands the current state of the development effort. In fact, as the system evolves, you might even find that you no longer have a development team and a customer team. Instead, you've got "a team".

Metrics and measurements

Burton Group recently published two popular reports on IT metrics, measuring IT’s business value, and justifying IT's value.  The new reports target Data Management and the Software Development Life cycle perspectives. 

I found Kirk Knoernschild's coverage of 'metriculation' a refreshing and healthy departure from the customary 'metrics bashing' or 'metric as a panacea' perspective espoused by others. A few key quotes:

"Many IT organizations are leery of using metrics. In some cases, such caution may be warranted, especially when metrics have been used deconstructively. Metriculation refers to the improper use of metrics. More succinctly, metriculation is when metrics lie."

"Although software teams may already capture specific metrics, it’s imperative that IT evaluates how well those metrics align with business objectives. It must be careful to avoid “metriculation,” where metrics convey misinformation."

"Internal IT metrics are a valuable tool for helping the IT organization improve its internal processes, but they aren’t much help when it comes to justifying investments. For that, the IT group must define metrics that measure its business value (i.e., the value that IT contributes to the business)."

For more information on metriculation and measuring value, read Kirk's blog entry and research report.

It's not what you do, it's what you call it ... huh?

Blogger: JP Morgenthal

Staying out of this "SOA is dead debate" is like trying to stay out of the circle at at Greek wedding.

It seems there's a good amount of traffic focused at commenting on Anne's blog entry stating that the principles of SOA are sound, but you don't want to call it SOA.  This has led to very satirical representations, such as the one by Miko Matsumura, calling it the "Artist formally known as SOA".  However, this notion makes the hair on the back of my neck stand up.

In response to David Chappell's thoughtful blog piece, I responded, "the whole sordid process has brought me full circle and I don't know that SOA was ever really born".  My basis for this statement is that there has never been broad spectrum agreement on what SOA means.  There's the OASIS Reference Model definition, the software engineering definition--I built a web service, therefore, I SOA, the Enterprise Architecture perspective--save the architecture, save the world, just to identify a few.

Moreover, the examples of successful SOA that have been put forth, primarily by the vendors, all look like re-hashed former architectures.  I see many examples of EAI, OOD, component architecture, BPM, workflow, etc. and mashups of these architectures used to form a solution, but I don't see anything uniquely SOA, unless you buy into the definition of SOA as having used an interface to expose these efforts as reusable chunks.  As I also pointed out in my comment on David Chappell's blog, "if you use a term that is amorphous and identify success by that term, then the success is circumspect."

The reason why we cannot summarily dismiss this notion of lambasting the term 'SOA' without throwing away the whole notion, is because at the core 'SOA' represented semantics--the semantics of business.  Its like the fact that no one talks about Iraq and the weapons of mass destruction anymore; the original premise has gotten lost.  The underlying principles of what is now known as the 'Artist formerly known as SOA' were the relationships between services and their semantic representations of the business' faculties.  It was a way to look holistically at the organically grown rats-nest of applications and their awkward "intertwingling" (Chris Haddad's superb description) and apply a methodical reorganization of those assets against a template representing the core business.

So, IMHO, to say "do SOA", but don't call it "SOA", is at the core of why so many have reacted so strongly to this message.  We hate the unknown.  It's better to have a bad name, then no name at all.  But, even better, would be to have a name that describes the task at hand.  I also believe that if you go management with a message of, "we should clean up our intertwingled application mess," you should probably be prepared to join the unemployment line, regardless of the fact that you would be acting in the best interest of the organization and undertaking an effort that could result in millions of dollars of savings amortized over a number of years.

In conclusion, I would like to leave readers with something they can replace SOA with as they are getting called on the mat about their support:

1. SOA is a bad word because it doesn't tell us anything
2. Think about applying a pattern of organization to your information technology infrastructure that closely mimics your business' core focus, along the way reducing redundancy and building out a common reliable business service infrastructure
3. As a result of developing out the business service infrastructure, you will need to respond to practicalities associated with security, reliability and change management
4. Extra credit: take the opportunity to build out a strong software development life cycle methodology and develop out metrics and expected ROI

Metriculation - Metrics that Lie

Blogger: Kirk Knoernschild

Metrics can be a valuable asset to software development teams in helping to improve their efficiences and measure their effectiveness. Unfortunately, metrics don't always provide the intended value. Sometimes, metrics lie.

Metriculation is a term I use to describe how metrics are made to lie. It's derived from statisticulation, a term introduced by Darrell Huff in his book, "How to Lie with Statistics", first published way back in 1954. There are many forms of metriculation, and it's a significant factor that affects the successful use of software development metrics.

Metriculation is not the same as using metrics ineffectively, or measuring the wrong thing. For instance, using LOC (lines of code) was once thought an effective way to assess programmer productivity. LOC has nothing to do with productivity. Code generation wizards can be used to create a component with thousands of lines of code, but it might take days to correct a nasty bug that requires changing only a single LOC. LOC does have it's value, however. Using LOC to help calculate the percentage of code under test, or to help with software estimation, are examples. Using LOC to gauge developer productivity is ineffective, but it's not metriculation.

Instead, metriculation involves using metrics to mislead. Downright deceive. Lie! For instance, in an effort to undermine the value of unit testing, a developer may claim that 75% of the system defects are found in code with unit tests. This form of metriculation, known as semi-attachment, is done by finding a way to prove what you want to prove by drawing false conclusions. Based on only this information, one might be drawn to the false conclusion that unit testing does not contribute to higher quality software. Unfortunately, what the developer may not have shared is that 95% of the code is under test, meaning that the remaining 25% of defects reside in 5% of the code. Given this additional information, we could have arrived at an entirely different conclusion - that unit testing does contribute to higher code quality. In this example, the metriculation was intentional, but that's not always the case. Often times, it's due to oversight. Regardless, metriculation is dangerous.

In addition to semi-attachment, there are many other forms of metriculation, all with numerous real world examples of how they've been used to push an agenda. These include selective use, biased samples, well-chosen average, fudging the numbers, overgeneralization, faulty assumptions, whiz bang graphics, and creative charts. Upcoming Burton Group research will discuss in more detail metriculation, and how we can deal with. As that material matures, I'll continue to share interesting snippets.

Software Process - Maturity, Formality, & Ceremony

Blogger: Kirk Knoernschild

The degree to which the software development process is defined, managed, measured, and controlled defines an organization’s process maturity.  Increased process maturity is a good thing because it’s an indication of an organization’s ability to develop and deliver software. Unfortunately, in focusing on process maturity, many teams fail to consider two other important software process classification schemes - formality and ceremony.

Process formality represents the discipline of the team in adhering to the practices defined by the software development process employed. Process ceremony represents the weight and rigidity of the software development process employed by the development team. Increased process ceremony corresponds to tighter controls placed on the development team. The difference between process formality and ceremony is subtle, but distinct.

For instance, a team may be very disciplined in capturing system requirements and documenting them by writing use cases. However, one team captures these requirements on hand-written notecards and reviews them with customers during weekly system demonstrations. Another team uses a standard use case template and requires customer sign-off on the requirements before development commences. Both teams are formal in that they capture and document requirements through use cases, but only the process used by the latter has a high degree of ceremony

Waterfall methods tend to be formal and ceremonial, whereas agile methods tend to favor formality with little ceremony. The Rational Unified Process (RUP) is a good example of an iterative method that wants to be formal, but often achieves that formality through ceremony. An unfortunate manifestation of RUP.

The unique challenges of individual software development projects vary widely. In general, process formality is a good thing while ceremony is wasteful and impedes progress. Only when teams lack the discipline to execute important lifecycle activities is ceremony necessary. Something to keep in mind as you look to increase software development process maturity.

Ivar On Being Smart

Blogger: Kirk Knoernschild

I arrived at EclipseWorld yesterday just in time to hear Ivar Jacobson's keynote titled "Be Smart". If you've never heard Ivar talk, it's a treat. Using some dry humor and a wealth of experience, he attacked this topic from a pretty fundamental perspective.

He started by talking about the traits of good software - reliable, useful, and extensible. It was extensibility, he noted, that is unique to software. Few other products need to be designed with extensibility in mind. But software is intangible and often considered infinitely malleable. Because of this, software must be extensible to meet expectations. To achieve this goal, it's important that we reuse components. Component here is used, I'm pretty sure, in the general sense. A component could be a third party framework, or it could be a service.

Unfortunately, Ivar noted that we've been trying to find ways to build good software for a very long time, but still haven't quite reached the tipping point. He pointed out that the software industry is truly enamored by fashion, possibly more so than the fashion industry (an example of his dry humor). To illustrate how we are so caught up in fashion (fads and trends), he pointed out some of the hot technologies of the past few years. Fifteen years ago OO was the rage. Ten years ago it was UML. Five years later, everyone was clamoring to jump on the RUP or CMMI bandwagon. More recently, it's been Agile methods that have caught our fancy. But in the end, none of it these fads have given us that magic bullet we're looking for. Why? Because processes and people don't develop software - people do.

For a long time, we've tried to use process to make people interchangeable, and tools to make less skilled people as effective as those with great skill. Unfortunately, that doesn't work. And as Ivar noted, it really isn't very smart of us to do that.

He went on to describe some "unsmart" things we do, and then talked about the smart thing we should be doing instead. For example, really big teams are unsmart. The smart thing to do is break that big team down into a bunch of smaller teams. He drew an analogy here to how we organize a sports team. Another example he cited was that many companies still try to document their requirement early in the lifecycle. But really, all you're left with after requirements documentation is complete is a mound of paper, but nothing executable. And how can we measure progress if we don't have a system? That isn't very smart. The smart way to proceed is through building a skinny system and incrementally add more capabilities to that system over time. Surround it with tests (and other executable artifacts, of course) that prove you've hit your mark. At this point, Ivar made sure to cite a variation on our Vantage Point theme by saying that smart people think big, but build in small steps.

There were a few other nuggets of wisdom thrust upon us by Ivar, as well. That ivory tower architecture isn't very smart. He noted that 80% of all enterprise architecture efforts fail. Where he got the number, I'm not sure. While Ivar has written eight books that have sold over a million copies, he said that nobody ever reads process books (again, his dry humor showing through). His point was that we have enough process, and we don't really need more. What we need instead, are good solid composable practices that offer guidance, and that smart people can figure out the details themselves.

He concluded with a joke. Two fools were standing on the street corner discussing what it takes to get rich. Up pulls a gentleman in a fancy sports car, and one of the fools decides to ask the gentleman his key to success. The gentleman pulls the fool aside and explains to him that you just have to be smart. The fool doesn't understand, so the gentleman illustrates with an example. He walks the fool across the street and puts his hand in front of a tree. He tells the fool to punch him in the hand as hard as he can. As the fool winds up and delivers his punch, the gentleman pulls his hand away at the last minute. "See, now that was smart of me", says the gentleman. The fool with a sore hand walks back over to his buddy who asks him what the gentleman said. "He said you just have to be smart. Let me show you.", said the fool with the sore hand. Given no tree was on this side of the street, the fool puts his hand in front of his face and says, "Hit my hand as hard as you can." Now that's not very smart.

Sometimes smart is just common sense.

Executable Artifacts

Blogger: Kirk Knoernschild

The last couple of posts, I've briefly mentioned the term executable artifact, which is any software artifact executable against another software artifact. A prime example of an executable artifact is a scripted test case. But there are many others, including software visualization tools, code inspection and analysis tools, many kinds of testing tools, and documentation tools. The great value of executable artifacts is that they avoid the loss of fidelity that often occurs in translation. Let's take an example.

Traditional project artifacts might include a requirements specification created using MS Word. Requirements are interpreted by an architect or designer and translated to an architecture and/or a design model. The model is then translated by a developer to source code. Test cases are also developed after a tester translates the requirements. Each of these artifacts should express the system consistently, albeit in different form and from a different perspective. But because the translation of one artifact is left to the interpretation of another artifact by the translator, there is no guarantee that the translation was done with great fidelity (ie. without loss of accuracy). This is why agile and iterative methods are valuable. They allow us to verify (at the end of each iteration) that the translation between requirements, architecture, design, code, and test were done with great fidelity. That is, prove the system does what it’s supposed to do.

Fidelity, or lack thereof, is why so many software projects experience difficulty late in the development lifecycle, especially if an iterative or agile method isn’t used. Early in the lifecycle, the loss of fidelity that occurs through translation is not recognized because nothing ensures fidelity is maintained. How do we verify that the architecture or design model offers an adequate solution as specified by the requirements? We have no way of knowing. There is nothing that proves correctness. Late in the lifecycle, as the degree of fidelity must increase (ie. tests executed against the system), the errors in translation surface. The only way to avoid loss of fidelity during translation is to ensure each artifact is executable and verifiable against the other.

Herein lies the problem with many tool suites today that promise traceability. They may link the artifacts, but they don't guarantee fidelity by offering verification that a loss of fidelity hasn’t occurred during translation. Now, let’s look at another scenario. Requirements specifications might still be created using MS Word. But simultaneously, test engineers are creating test scripts, while developers are writing the source code that satisfies these tests. An automated build includes execution of these test scripts, as well as code analysis and inspection tools that analyze code quality, visualization tools that illustrate the structure of the system, change reports that show what’s changed since the last software build, and more. These high fidelity executable artifacts provide a team with accurate feedback that’s used to assess current project health and chart their future path.

Until vendors provide tools that ensure no loss of fidelity, this is the best we’ve got. Today, the most successful development teams are leveraging executable artifacts along with agile and iterative methods to ensure fidelity is maintained throughout the software development lifecycle.

Improving Software Delivery

Blogger: Kirk Knoernschild

Many software development teams already do many things well, and these practices should be built upon, not discarded as teams seek to improve software delivery. Instead of attempting a large process improvement effort, teams should identify and eliminate the pain points of their existing delivery effort, and this is where the practices espoused by many Agile processes shine.

Suffering through failed delivery cycles? Leverage continuous integration to ensure your software product is always functional. Low software quality your problem? Develop a suite of automated tests that can be run on demand. Struggling to measure the current state of the development effort? Create a project dashboard that increases the transparency of your software development effort. Each are simple, incremental improvements to your software delivery strategy that help increase your ability to deliver high quality software.

Here are a few nuggets of wisdom to chew on as you seek to improve software delivery.

• Tools don't solve problems - Before you buy that shiny new hammer, make sure it's a hammer you need. Does  your existing software delivery strategy rely heavily on modeling to deliver great software? Or are you hopeful that by purchasing the modeling tool you'll discover a better way to deliver software that has escaped you in the past? If you really feel the need for a power tool, make sure it's a tool that fits your process.
• Traceability is a myth - Many teams are enamored with traceability. Changes to requirements can be traced through the analysis and design model into the code through the components and onto the executable nodes. But traceability is fundamentally flawed due to synchronization issues across artifacts. Teams do not possess the discipline necessary to maintain consistency across all artifacts, making the source code the only true artifact representing the current state of the system. Build on that idea, and surround your source code with executable artifacts that offer valuable insight to the code's quality, functional correctness, and feature set.
• Software delivery must be disciplined, not ceremonial - Significant phases of the software lifecycle should not be marked by ceremonial milestones. Many teams celebrate requirements sign-off. Design is done; throw a party. Such ceremonial milestones offer a false sense of progress. On the other hand, delivering functional software on a frequent and repeatable basis requires tremendous discipline. The discipline to continuously test that software through the evolutionary growth of the system is a fine example.
• Conform process to people, not people to process - Software process cannot be made constant because the people involved in the development effort continuously change. People cannot be made pluggable parts because each is an individual that brings different experiences and personality to the development team. Forcing people to conform to process stifles innovation.
• Source code is a corporate asset - At the end of the day, the reams of paper consumed documenting requirements and design models are never used to judge the success or failure of the software system. When all is said and done, the one artifact offering accurate feedback on the quality of the system is the source code.