An Example of Agile Methodology, with a bit of a struggle

We are in the process of re-designing our website launch. The site will be based on Wordpress CMS, new content, new functionality, some revised branding, and new layouts. It's been a long time coming. I've been trying to think of an approach to launch the website iteratively so that its not contingent on a Big Bang launch and dependent on everything being done to launch. Unfortunately, I keep circling back to thinking that a partial launch of the site would diminsh our brand due to limiting the user experience. Therefore, I am currently aimng to launch with most of the requirements we've laid out for this project and not launch iteratively. Granted, some requirements can be de-prioritized for a future release, but the baseline site ("product") needs to be all (most all) or nothing for now. Now, this can all be bundled into a "Release", and requirements ("User Stories") tackled in a Sprint like fashion, but ultimately the struggle was in producing a finished product within a Sprint...that I didn't feel comfortable with, as we only have 5-7 seconds to grab a User's attention on your site, and a site that isn't 100% ready would lose the user pretty quickly. So, a bit of a struggle on applying Agile principles to a Released product in this situation.

Why I attend Oracle Open World

We live in a complex world. A world that is constantly changing. Businesses need to be able to adapt and evolve, rapidly, or face the consequences of failure. How do companies keep up with new customer demands, evolving business processes, new legislation, industry regulations and compliance, and business channels fueled by the Internet, and more? How do organizations protect against the risk of failure? We attend Oracle Open World, a forum to collaborate with peers, industry advisors, and leading experts on how to create and leverage solutions to solve complex business problems. Providing attendees contribute their expertise, knowledge power, intellectual capital, demonstrations, and leading practices so that other organizations have not only a proof point, but a roadmap to success. Others attend to learn, collaborate, network, and inquire how to design their solutions appropriately. It is a melting pot or ideas, solutions, and approaches for everyone to leverage. Opportunities abound to discuss the best businesses use of Oracles technology, so we can be more agile, flexible, and dynamic to meet the business challenges of today-- and address the unforeseen issues of tomorrow. Decisions will be made at Open World that will impact many organizations—product direction, architecture, and best use of technology. It’s important to remember that in today’s technology marketplace, we have many choices, and we have to be careful that we select, design, and implement the right platforms that will provide the appropriate solutions for our business—we must be equipped for success. Technology decisions come with risks that include stability, scalability, agility, performance, and meeting business expectations. No company can afford to make the wrong technology decisions, and this is why Open World is so important. Attendees can count on Oracle Open World to provide the proper insight, approach, and products to not only mitigate risks, but provide a roadmap to success.

To Agile or not Agile, that is the question

Following are the principles of Agile I like to incorporate into projects:

• Organizing phases into 2-4 week iterations (Sprints) so that there is distinct product or deliverable assigned to each iteration.
• Performing User Acceptance Testing (UAT) early in the system life cycle, rather than the end of the SDLC, to gather business user feedback early and often.
• Designing the system with the expectation of change. This allows agility and flexibility. I assume that the services we build will need to be dynamic with the changing business climate and will need rapid.
• Maintaining an On-going "Product Backlog" which is ranked and prioritized list of requirements. The list is constantly re-ranked and prioritized and the top candidates are inputs into the next Sprint iteration.
• Brief daily Status meetings (Scrum) to check progress, roadblocks, and planned activities.
• Collaboration amongst the team and amongst the business team is key to vetting solid and practical frameworks
• Keep it Simple. Making governance frameworks and patterns overly complex runs the risk of limiting adoption
• Business Processes are the foundation of what applications have as an objective, and in Agile the business stakeholders are a key to driving the development process (having a Product Owner).
• Governance requires Multi-stakeholder team, consisting of representation from various IT and business teams.
• The use of a Burn Down Chart can help all stakeholders track progress of the overall initiatives.
• Rapid. Using Agile will force teams to get working services and deliverables in a quicker fashion and forces accountability across the team.. This also has a good impact to team morale (developers tend to enjoy the Agile process)
• Good for creating a Knowledge base to capture "lessons learned" early and often for continuous improvement.
• Agile reduces waste; Captures bugs early, avoids goldplating, committed team members

Some of the more radical Agile principles that I don't necessarily prescribe or apply include:

• Limitation of documentation. In projects, especially around governance, certain documentation is key such as patterns, SLA's, contracts, frameworks, etc
• Self-organizing teams. I feel that leaving the teams to self-organize can be a bit optimistic and instead I feel a project sponsor is best suited to help organize the team, with our strategic input on personnel skills and capabilities.
• Documenting User Stories (Requirements) on stick notes. While this is good for collaborative working group sessions, I find it is very important to electronically capture and publish the User Stories for all team members to view through an online, browser enabled tool
• Individual iterations over processes and tools. I feel its important to follow a disciplined process and using the right tools to build services and applications is important as well.
• Not following a plan. I feel it is important to have a high level Roadmap for tackling projects, and maturity model that outlines milestones to achieve adoption and capability achievement.

Virtualization Support is the Elephant in the Cloud Room

Cloud Computing adoption is taking off. Two of the major principles of Cloud are: (1) resource pooling through mulitenancy (2)Elasticity. Multitenancy is the ability to have a single resource serves multiple clients. Example in Cloud is having multiple customers served by the same physical server. Elasticity is the ability to add or plug-in resources, fairly dynamically, to scale the server up or to scale down. For example, swapping in CPU, memory, disk space, etc.

Both of these principles are reliant on virtualization, the ability to run multiple, independent instances of software or hardware within a resource that was originally designed for a single use. The best example is a Server hosting multiple, independent operating systems that each are performing seperatlely from each other.

The leading vendor in the virtualization space is clearly VmWare. VmWare has been around the longest, and has the greatest market footprint, and has the most efficient use of hypervisor. Challengers in virtulaization space include Oracle, Microsoft, and few others.

The problem with VmWare, or the elephant in the room to speak of, is the # of enterprise software products that are still not supported on VmWare, namely Oracle. The largest example is Oracle, since they are the leader in enterprise software. Oracle software is only supported on Oracle's own product-- Oracle VM. Now, I do know there are a lot of customers running Oracle databases and Oracle middleware on VmWare and haven't had any issues yet. But, if there is an issue, these customers must understand their environment configured with VmWare is not supported by Oracle, Inc. You will be required to reproduce your issue in a non-VmWare environment OR on Oracle's VM software to get bug and issue support. This is scary, especially the number of customers I know who run Oracle on VmWare. Just the sheer possibility of losing production data or having long system downtime due to a non support issue, and then having to reproduce the entire environment to get support is enough risk for me take a strong look at Oracle VM so not to impact my Production systems. However, I'm no dummy and realize a lot of customers are running on VmWare just fine and haven't seen any issues, yet. I'd ask how advanced or complex their environement is? Are they doing RAC, Clustering, Load Balancing, Data Replication, or other advanced configurations? All of these could add complexity and impact the environment on a virtualization architecture. High performing applications that require this level of configuration could be risky in a VmWare environment, especially since VmWare does its own version of memory management, throwing off software like Oracle that manages its own SGA and PGA structures. Huge considerations for any customer thinking about virutalization-- lack of vendor support is serious stuff even if you think it works ok.

A second consideration is cost savings. This is one of the main drivers for virtualization. Squeeze more out of my existing resources instead of using it for a single purpose. For example, if I buy a physical server and its CPU and memory is very underutilized, then I can virtualize more Operating Systems onto the server and use the server for multiple purposes. This is good for hardware savings and not having to procure more hardware for your software applications, but won't buy you anything with your software licensing savings. the large software companies are very aware of this, and they will not give you a break on your software for putting more on a single resource. This is why they will not allow tools like VmWare to emulate the CPU's to make the customer's licensing less expensive.

I know VmWare has lots of examples where software on their product runs issue-free. This is great and I applaud the fact that it should work ok in a basic configured environement. However, VmWare cannot control the other software vendors like Oracle. I would ask to please get Oracle products officially supported on VmWare, and then we can all rest easier at night.

So, Big Elephant in the room-- to VmWare or not VmWare? No virtualziation, clearly makes a "Cloud Environment" difficult to achieve, especially losing multitenancy and elasticity principles. So, your first option is to ask your vendor what their policy is on virtualization support. If its a company like Oracle, consider using their Oracle VM product if you still need virutalization. VmWare may be your corporate standard for virtualization, but its not supported, and that is enough risk to avoid it until it is fully supported.

SOA Evangelism is still an Uphill Battle

I recently attended a conference, and was happy that I wasn't speaking so I could sit back and enjoy being an attendee only. The conference was focused at and attended mostly by technologists, lots of developers in the house! The conference also had an entire track dedicated to SOA over the 3 day event. I was so excited to see that a conference that wasn't dedicated to SOA or BPM had an entire track over the 3 days on SOA.

I started off the conference by attending the SOA sessions. Logic would tell me to go to other sessions-- ones that I was unfamiliar with, so I could learn more about areas I wasn't as entrenched in. But, I threw logic out the window, and had to start where my heart is and see what other practitioners have to say about their SOA experiences.

The SOA sessions were interesting to sit through, but I was really surprised and disappointed that these SOA sessions were poorly attended. At a conference that had over 1,000 attendees, the SOA sessions struggled to get 10 attendees per session, while other sessions were "standing room only". The few folks who did attend, were trying to learn SOA 101 and how to get started with SOA at their respective organizations.

Despite the low attendance and interest at the SOA sessions, I still took it upon myself to preach SOA to attendees I networked with throughout the entire conference-- whether it was lunch, booth conversation, breaks, or even evening social hour, I spoke the SOA gospel. I quickly realized that most folks I encountered, struggled with the fundamentals of SOA and the value proposition it brings to their architecture. The 2 main excuses I heard from attendees about not embarking on SOA were 1) SOA is overkill for their organization (they don't think they need it) 2) SOA adds more complexity to the architecture and environment and the last thing they need is more complexity. Through questioning and examples, I tried to prove that both these "excuses" were incorrect. However, when your at a conference and only have a few minutes to get your point across to someone you just met for the first time, it's difficult to fundamentally change people's minds. At a minimum, I am confident I planted a few deep seeds for folks to think about or read more about SOA when they return back to their organizations.

It seems SOA evangelism is an uphill battle. Most folks I meet are non-believers when I meet them and they need to be converted to SOA. They say IT beliefs are like a religion, so we know conversion can be a difficult endeavor. I am ok with this responsibility and wholehearteldy accept it. My preferred approach towards gaining SOA acceptance is to engage and prove value through a Proof of Concept. I feel this is the best way to show SOA benefits. It's also important to understand that SOA truly is a paradigm shift-- a new way of thinking in organizations. With SOA, applications and systems aren't managed as the primary asset; rather, the service is. A lot of folks struggle with this concept, especially since they have been working in a single paradigm and only understand systems and applications throughout their careers.

What's the solution to overcoming this uphill battle? Continuous education, evangelism, and making sure demonstratable value can be achieved through proof of concepts and prototypes. Show your colleagues the money! IT needs to accept SOA before you can bring it to the business teams, so make sure you don't ignore the developers in your organization-- they are important stakeholders that need to be part of the SOA Journey from the beginning stages. Show them the light, and live by the motto "If you build it, they will come"!