Posted by Reint Jan Holterman around lunchtime: June 28th, 2010
Virtualization and cloud computing have exploded over the past few years. A recent study shows that 90 percent of businesses have implemented server virtualization at some level and Gartner estimates the current market for cloud services is $46.4 billion and will reach $150.1 billion by 2013. With other estimates saying business applications can be made three to five times less expensive and consumer applications five to ten times cheaper, it’s no wonder it’s taking off.
Among other benefits, virtualization and cloud computing are helping companies remove physical dependencies from network resources, respond faster to changing IT-infrastructure needs, and lower overall costs. While this is all well and good, as companies add more and more virtual resources to their network, they struggle to keep track of them. The reason? Virtual sprawl.
(more…)
Posted by Gero Vermaas in the early evening: June 21st, 2010
This is the seventh post in a series of blog posts discussing Lean Architecture principles. Each post discusses one principle. Applying these principles results in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. The seventh principle we discuss is called “Architecture Initiated by Business Goals“. (more…)
Posted by Rik de Groot in the early afternoon: June 18th, 2010
Working in multidisciplinary teams is common in Agile. In practice this means that the team consists of people with different skills, but work in the same dimension (for instance software). What about cross dimensional teams? In cross dimensions teams not only the skills differ, but also the area of expertise. For instance developing an electronic device includes electronics and software. They work on the same project, but can they act as one team?
(more…)
Posted by Reint Jan Holterman in the early morning: June 14th, 2010
IT organizations often face issues when deploying applications in an Agile environment, in part, because there are more releases to deploy. Due to the nature of Agile, development teams are able to deliver working tested software in much shorter iterations. While this is great for the company, as they can have better flexibility and shorter time to market, it often creates a backlog for operations teams who need to deploy the applications as quickly as they’re being delivered.
Before Agile, releases usually took place every two to three months; whereas, now, issuing a release every two to three weeks is standard. As a result, the improvements in productivity and quality for development when using Agile can be quite astounding, gaining around 400-500 percent. So, with development teams delivering a practically constant stream of software packages, operations teams need to be able to deploy them just as quickly to keep business objectives aligned.
Deploying releases manually is a complicated process that is only exacerbated by issues of virtual sprawl and poor upkeep of scripts and instruction manuals. However, having an automated deployment process keeps these frequent releases on schedule and error free. With deployment automation software, IT organizations are able to bridge the gap between development and operations teams, enabling them to maintain the higher productivity levels, shorter time to market, and other advantages Agile brings to a company.
Deployment automation allows IT organizations to continue to safely and reliably deploy their software components in an Agile environment while maintaining good cooperation and delivery between development and operations teams.
This is a hot topic in the industry right now and will be the focus of an upcoming webcast that we are sponsoring and presenting in conjunction with CM Crossroads this Thursday, June 17, at 1pm EST. Andrew Phillips, VP of Product Development at XebiaLabs, and Bob Aiello, Editor-in-Chief of CM Crossroads, will discuss the issues IT organizations face when deploying applications in an Agile environment and how deployment automation can ensure seamless transitions.
Click here to register and join the discussion, and feel free to leave a comment below if you’d like a specific question answered. Hope to see you there!
Posted by Robert van Loghem mid-afternoon: June 13th, 2010
Last December I wrote my first part on the Future of Deployment explaining the difference between big ol’ servers with a gazillion applications and lots of new shiny small servers with each its own application. This time I’m going to go to the cloud or your virtualized servers and give you my vision of how we are going to package and deploy applications in about 3-5 years.
How we used to deploy an application
Well you all know this one by heart: You get your environment up and running, like, install an application server, setup your database, choose a sql script to run against the database, configure resources and deploy the application in the application server. After everything is in place you start the whole bunch and bask in glory!
Does the above deployment scenario apply to virtualized/cloudy environments. Yes it does, of course! The environment setup is greatly simplified, using stuff like AMIs or virtual images aka appliances 
you get your database or application server out of the box but configuring and installing the application and configuration/resources is still the same old boring cumbersome task.
(more…)
Posted by Wilfred Springer mid-morning: June 12th, 2010
The Dutch NoSQL community is alive! Now, if you are new to NoSQL and you happen to have a Relational Database background, then rest assure: the NoSQL movement is not a militant group trying to get rid of SQL altogether. The N.o. in NoSQL represents: Not only. In the NoSQL community, we are looking at alternative ways to handle data (in particular big data), and it turns out there a myriad of solutions popping up these days, such as:
Posted by Sander van den Berg around lunchtime: June 11th, 2010
This is the sixth post in a series of blog posts discussing Lean Architecture principles. Each post discusses one principle. Applying these principles results in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. The sixth principle we discuss applies to the process of architecting and is called “Iterative Architecture Development”.
Posted by Geert Bossuyt in the early morning: June 11th, 2010
There are many misunderstandings about Agile and what it is or is not.
I’ve met some people who were really convinced that ‘Agile’ and ‘Scrum’ are like synonyms. Or who think ‘Agile’ is a synonym for ‘flexible’.
Both are not true. If Agile would have just been about flexibility or responsiveness, I suppose they would have called it ‘The Manifesto of Responsiveness’ or something like that. However they didn’t so there must be more to it than just the Responsiveness.
Agile is a mindset. A set of principles to guide you in the choices you make.
Posted by Sander Hautvast mid-afternoon: June 4th, 2010
In this episode of the middleware pitfalls top-10 we want to discuss the merits of a clean and standardized set of (test) environments. Some refer to such a set as DTAP, an acronym for Development, Test, Acceptance-test (or pre-production) and Production. From here on the text contains capitals to indicate an environment. Basically the situation is like testing itself: you will never get it 100% right, but it will help you a lot if you invest in a sound, maintainable DTAP.
Posted by Geert Bossuyt at around evening time: June 3rd, 2010
Story planning is a technique to facilitate commitment.
The ultimate goal of Story planning is to make a sprint planning that is really understandable and clear for every body. Something you understand so good that you can really feel whether it is doable or not. This is what you need to be able to commit. As a person and as a Team.
It’s a way to implement the Sprint planning and Sprint review session(s) and it serves as a great base for the standups and has proven to be very useful in many different cases.
When it’s hard to complete an entire story before the end of the Sprint.
When there are so many tasks in a Sprint that everyone has lost the overview.
When for some reason there is an anxiety to commit to a Sprint.
When planning a Sprint is taking a lot of time ( more than 1/2 hour/sprintweek )
The outcome of working with the Story planning is a highly focused and committed Team with maximal fun and productivity as a result.
Categories
- Java (311)
- Agile (181)
- General (136)
- Scrum (67)
- Architecture (64)
- Testing (59)
- Performance (46)
- Middleware (55)
- Deployment (37)
- Xebia Labs (38)
- SOA (31)
- Podcast (31)
- Project Management (28)
- Tools (25)
- Uncategorized (20)
- lean architecture (20)
- Quality Assurance (17)
- Articles (13)
- Virtualization (19)