Tuesday, August 31, 2010
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.
Wednesday, August 25, 2010
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.
• 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.
Thursday, August 19, 2010
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.
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.
Subscribe to:
Posts (Atom)