Tuesday, June 08, 2010

Current challenges for Application Performance Engineering

Application performance engineering is a discipline encompassing expertise, tools, and methodologies to ensure that applications meet their non-functional performance requirements. Performance engineering has understandably become more complex with the rise in multi-tier, distributed applications architectures that include SOA, BPM, SaaS, PaaS, cloud and others. Although performance engineering ideally should be applied across the lifecycle, we’re seeing more factors that unfortunately push it into the production phase, typically to resolve problems that have already gotten out of hand. That clearly a tougher challenge, so how did we get to this point?

In the client-server past, performance optimization was something that folks in the IT department typically figured out through trial and error. Developers learned to write more efficient database queries, database administrators learned to index and cache, and system administrators monitored CPU and memory to upgrade when needed.

As application architectures started to get more complex, the dependencies increased and it was harder for one team track down problems without chasing their tail. More organizations adopted something that was previously only used by enterprises with highly scalable, reliable mission critical applications – the performance testing lab. Vendors like Mercury created popular load testing tools like LoadRunner, and organizations invested millions in lab hardware and software in an attempt to recreate production environments that they could control for testing purposes.

Unfortunately, these performance labs became very difficult to cost justify. First, it always seemed to take too much time and money to setup the realistic test environments you’d like, particularly as apps became more distributed. Next, projects were often already behind schedule when it came time to test, and so lab times often had to be cut short. Factors like these minimized the lab’s value, but the real killer was the high maintenance costs for all that hardware and software, along with the data center and staff.

This put many IT organizations in a tough spot. With limited means to perform system-wide performance testing, and the inclusion of more SaaS/PaaS/cloud services in their architecture, they had to make due with whatever subsystem level performance testing they could get. After that, its finger-crossing and resigning yourself to further optimization in production.

Unfortunately, production can be a very frustrating place to try and optimize performance, particularly when you have performance problems and growing complaints from customers, partners, etc. It’s in these pressured environments where you need true performance engineers that follow a methodical and systematic end-to-end approach. Performance bottlenecks can reside in a myriad of places in highly distributed architectures, and you need to follow a disciplined methodology to analyze dependencies, isolate problem areas, and then leverage the best of breed tools to trace, profile, optimize, etc each of the tiers and technologies in the application delivery path. This takes a lot of skill and expertise.

In short, the challenges faced by today’s application performance engineer in production settings is a far cry from the client-server days of in-house tuning and experimentation. We expect that the role of Performance Engineer will grow in importance as SOA, BPM, cloud, and SaaS/PaaS implementations increase, and until more viable pre-production system performance testing options are available to rise up to the challenge.

Friday, October 23, 2009

SOA Manifesto

Here's a few quick links:

The MomentumSI SOA Manifesto from 2007:

Our discussion forum on the 2009 SOA Manifesto:

The 2009 SOA Manifesto:

Sunday, June 21, 2009

The Case for Expropriated Reuse

Expropriated Reuse is a form of reuse that focuses on the here and now. The goal isn’t to define some new service and hope for ‘accidental reuse’ or even to put forward a case for ‘planned reuse’. Instead, it’s the act of going out and finding redundant code that already exists across multiple systems and turning it into a single shared service. I’ll repeat that: Find redundant code and refactor out the common elements into shared services. This ALWAYS results in multiple consumers (or mandated consumers, if you prefer).

I’ll give a quick example. Over time, company X had ‘accidentally’ created 5 software modules that existed inside of larger applications that all did some form of ‘quoting a price to customers’. This led to 5 teams maintaining it, 5 sets of computer hardware, etc. Expropriated Reuse is the act of going to the applications and cutting out the common elements and turning them into one shared service. Note that this is different than application rationalization or application consolidation that tends to use a nuclear bomb to deal with the problem. We’re recommending sniper firing with a bit of additional precision bombing.

The reasons that we do this are mostly financial. We want to reduce the amount of code that has to be maintained and operated. We want to reduce our costs. There are plenty of other reasons like increased quality, time-to-market, etc. but I’m done with those softies. The case is cold hard cash. Show me how to save money or go away.

IMHO, the new SOA agenda is about expropriated reuse. The SOA Program must actively identify opportunities to make the enterprise software portfolio more efficient and less costly. Just like in city planning exercises we must acknowledge the needs of the community over the needs of the few. And I’m in agreement with Clinton that ‘we should never waste a good crisis’. Reduced I.T. budgets have created a ‘crisis of efficiency’ in virtually all of our clients. The imperative is to find ways to reduce budgets in the short term and over the next 3-5 years.

To quote Todd Biske, “… a common analogy for enterprise architecture these days is that of city planning. … (does) your architecture have more parallels to the hot political potato of eminent domain? Are you having to bulldoze applications that were only built a few years ago whose residents are currently happy for the greater good? What about old town? Any plans for renovation? If you aren’t asking these questions, then are you really embracing enterprise SOA?”

I’ve been wondering: Should all SOA programs that do not have the authority to issue an order of ‘eminent domain’ on the software portfolio be shut down? Does your SOA program have a hunting license to go find inefficiencies / duplicate coding and to issue an order of eminent domain on that code? Can you imagine what our country would look like if we couldn’t issue an order of eminent domain to capture land for our highways, bridges or railroads? Can you imagine if we didn’t have the ability to implement ‘easement by necessity’? Consider your town/neighborhood and think about the following: Railroad easements, storm drain or storm water easements, sanitary sewer easements, electrical power line easements, telephone line easements, fuel gas pipe easements, etc. What a mess it would be. The crisis of budgets must draw out the leaders. If you haven’t already been issued a hunting license, it’s time to go get one.

So I’ll answer my own question. If you’re SOA program is responsible for watching the blinking lights on your newly acquired SOA Management tool, or making sure that people enter their ‘accidental’ services into your flashy registry, I’ll recommend that they shut you down. This is a waste of time. The SOA group must be given the imperative and authority (a hunting license) to find waste in the enterprise and to destroy it. SOA isn’t about policing people on WS-Standards or similar crap – it’s about saving your company millions.

The Case for Planned Reuse

In my last post, I argued that the concept of ‘accidental services’ or ‘build it and they will come’ is a bad idea – because … they typically don’t come. Services that are created with a very specific consumer in mind are typically limited in capability, scope and result in limited reuse.

The MomentumSI Harmony method suggests that service analysis be performed on the first consumer’s needs as well as potential consumers that aren’t in the immediate scope. This is easier said than done. How do you identify the requirements of a service if you have ‘phantom consumers’?? The short answer is that there are techniques that involve looking at UI models, process models, data models and other artifacts that will give you insight into the domain. The result is a list of potential consumers and a plan for their eventual consumption. The point is that there are techniques to help organizations define services according to a plan – and doing so leads to increased reuse and a better software portfolio.

Again, Planned Reuse is most effective when you’re working in a new domain and you don’t already have a bunch of conflicting/overlapping software that exists. The immediate project might call for an ‘Order Service’, but you know that the service will eventually be called by the Web eCommerce system, the call center software, the B2B gateway, etc. Those projects aren’t in scope – but you consider their needs when designing the service.

This is all fine, but what happens when you’re analyzing a service for an immediate project that clearly should be called by existing projects/software? This is the case for Expropriated Reuse.

The Case Against Accidental Reuse

"Accidental Reuse" is a term that I've been throwing around a lot lately. In layman's terms, it means, "If you build it, they will come." This notion has been disproved in virtually every field (except in the Field of Dreams) - and I suggest it is even more unlikely in the field of software engineering.

It has been my observation that most software engineering teams suffer from a bad case of 'not invented here' syndrome. We work in a discipline that is not regulated and the certifications are a joke at best. Most programmers don't have engineer training - and most architects have learned from doing and observing. In short, there are good reasons for one team to not fully trust the output of another team. We also have the issues of human entitlement. It's been my observation that a generation of software developers has been created who feel that they are entitled to 'not be bored' and 'deserve cool problems'. Once again, we have people who feel the need to create new stuff - not reuse.

I could go on - but I'm guessing there is no need. Anyone who has been in the industry has seen the problems. This leads back to my original point - accidental reuse is a bad idea. And here, I'm as guilty as the guy sitting next to me on the last 20 panels where I've been on telling the world to 'build it and they will come'... design for reuse... create services... register the services... and they will come. Apologies.

Most SOA report cards that I get still show metrics on: how many services there are, how many consumers there are or how many times the service has been called. These are fine metrics but in my humble opinion leave behind one very important metric: how many unknown consumers use the service? (accidental reuse, planned reuse & expropriated reuse)

Now it gets interesting. My aggregate data shows that most services are built with one consumer in mind and almost 80% of all transactions go through the original consumer. Less than 2% go through 'accidental channels'. Of the 2%, most of those were for externally facing systems (B2B) where advance knowledge of consumption is limited or they were in 'technical' or 'entity' services where they offered limited functionality and in some cases, limited return.

The remaining 18% go toward 'planned reuse' or 'expropriated reuse'. This number is too low - but this is the opportunity. More on this later...

Coming next:
- The Case for Planned Reuse
- The Case for Expropriated Reuse (right of eminent domain)

Saturday, December 20, 2008

New Blog on Cloud Computing

SOE isn't dead but my primary go-forward blog will be:
http://cloudv.blogspot.com

Friday, November 07, 2008

Nomination for Federal CTO

From the Barack Obama campaign site:

"Obama will appoint the nation's first Chief Technology Officer (CTO) to ensure that our government and all its agencies have the right infrastructure, policies and services for the 21st century. The CTO will ensure the safety of our networks and will lead an interagency effort, working with chief technology and chief information officers of each of the federal agencies, to ensure that they use best-in-class technologies and share best practices."

I nominate Tim O'Reilly as the first Federal CTO. Do I hear a second??

Friday, October 24, 2008

Thursday, October 23, 2008

16 Corrections on Cloud Computing

In March of 2008, RedMonk analyst, James Governor, submitted his list of "15 Ways to Tell if it's not Cloud Computing".

The consultants at MomentumSI have found 16 corrections: