Niklas Bjorkman wrote: Firstly I agree with your conclusion. NewSQL takes the best of the traditional databases and NoSQL databases to combine the benefits of both worlds. I do not agree that NewSQL vendors focus on giving scale-out features to transactional data. The NewSQL market is focusing on giving true ACID support combined with extreme performance, stepping away from the traditional relational structures in databases. A lot of developers appreciate the ease of accessing data using SQL and I think we will see more and more databases supporting standard SQL.
As you said - NewSQL databases often maintain the...
I must admit that before I began reading this book I truly thought it was going to be another twisted story of an attempt at agile that failed in everyone's eyes except for those that needed to say it was a success. That is what I am used to.
It is kind of like when I am on a product reference call to CIO. The product is always great and the company who sold it is always wonderful. Why some people think the CIO is going to say they didn't do their due diligence when picking a vendor, and the product and company we are asking about sucks, is beyond me?
They never do. The same is true of almost all the agile projects I have seen. They end over budget, buggy, and pretty much the same way most projects end that use any other process, but they are always deemed a success by those involved.
I was ready to tell myself I was correct in my assumption when I got blasted on page 2 with the Agile Manifesto, but decided to give them to the end of the chapter. In the next section of the chapter they caught my attention with the last of a list of 6 topics which was their take on Agile/Lean Principles. Number 6 was practitioners should define agile/lean practices.
I find myself saying the same thing all the time on a ton of different projects. When it comes to leading large complex agile projects, if you have not come up through the ranks being mentored on successful agile projects, and learning through experience, not books, you have no business defining process and leading the project. I have met very few people who agree with this line of thought and it impressed me that the authors did.
That one line of thought pushed me to read chapter 2. Again I was pleasantly surprised with the authors discussing the need to engineer a solution. Not implement a process, but engineer a solution. By the end of this chapter the authors had done a great job summarizing where their teams use their resources now and assembled some excellent development objectives.
Another thing the authors discussed was the capacity of their organization to absorb change. This is something that is almost always overlooked when bringing in new development processes, agile or not, this is something that needs to be looked at throughout the entire organization. This is usually just isolated to the development teams, but the new processes affect every department when they are implemented correctly.
At the end of the chapter the authors list their achievements: -2008 to present overall development costs reduced by 40% -Number of programs under development increased by 140% -Development costs per program down 78% -Firmware resources now driving innovation increased by a factor of 8 (from 5% working on new features to 40%)
I am sure these seem exaggerated, and that is what I believed until I read the next two chapters. Over the course of the next two chapters the authors fully won me over. They proceeded to outline implementing a Software Product Line using their own process language. I know from my own experience that when Software Product Line Engineering is done correctly it will always produce improvements like those listed above.
The authors nail exactly what enables their ability to implement an iterative agile process, and that would be investing in the right architecture. Any sizable project that doesn't invest in the architecture and claims they are able to pull off the project in an agile way is full of crap, period.
Product Line Engineering is the process that offers the highest level of agility over all other processes. It is tailorable for different levels of ceremony and is therefore able to run lighter than Scrum given the right team and right environment.
One of the main benefits of Product Line Engineering is the ability to collect metrics and in Chapter 5 the authors identify how to take advantage of them the right way, which is not to manage by metrics, but to use the metrics to understand where to have conversations about what is not getting done. Chapter 5 also outlines their iterative process.
The book continues to cover excellent process practices throughout the rest of the book, and they are applied to a real world project which drives home their value even more. Below are all the chapters included in the book.
Chapter 1. Agile Principles versus Practices Chapter 2. Tuning Agile to Your Business Objectives Chapter 3. Aligning Architecture with Business Objectives Chapter 4. How to Establish a New Architecture Using Agile Concepts Chapter 5. The Real Secret to Success in Large-Scale Agile Chapter 6. Continuous Integration and Quality Systems Chapter 7. Taming the Planning Beast Chapter 8. Unique Challenges of Estimating Large Innovations Chapter 9. Our Take on Project Management for Large-Scale Agile Chapter 10. Organizational Approach: Managing to Disadvantages Chapter 11. Effective Agile Development Across U.S. and Indian Cultures Chapter 12. The Right Tools: Quantum Leaps in Productivity Chapter 13. Real-World Agile Results: HP FutureSmart Firmware Chapter 14. Change Management in Moving Toward Enterprise Agility Chapter 15. Differences in Our Perspective on Scaling Agile Chapter 16. Taking the First Step
Unlike a lot of books I have read on implementing agile practices on large scale projects I believe the results of this project were reported accurately.
I also believed the results were achieved with an iterative agile process. They are honest about the issues they ran into and they hammer on prototyping for architectural issues, which is definitely the way to go.
The author's writing styles make the book an easy read and the story that is told along the way is a very interesting one. I did not get bored with even one page of this book.
This book is a must read for any CIO, Enterprise Architect, Software Architect, Project Manager, or other IT roles in charge of or involved with large scale initiatives that they are hoping to pull off in an agile way. The book tells the story of how to achieve success based on a real world success, not a made up fictional case study.
Although I started with ColdFusion for application development, I did plenty brochureware sites with HTML. I believe the version was HTML 2.0 for IE 2.0. I lived in the browser world for years doing ColdFusion, ASP, and HTML sites. When winforms and Smart Client with web services...
Compuware Corporation has announced the convergence of dynaTrace PurePath® Technology and the Gomez Performance Network, creating a powerful User Experience Management (UEM) solution. Compuware now offers a APMaaS solution that provides a complete UEM offering, including real-use...
The saying “if it doesn’t exist on the Internet, it doesn’t exist”[1] is ringing truer every day. Nowadays, it is hard to imagine most businesses without an e-commerce platform, let alone without a web presence at all. Since e-commerce is becoming the new standard, e-commerce per...
Service Component Architecture (shortly referred as SCA) is a technology for creating services from components. SCA is a set of OASIS standards and part of it is developed with the collaboration of vendors from open source community, referred as “OSOA” Open SOA. SCA helps to buil...
Boston-based Cloudant and its NoSQL distributed Database-as-a-Service (DBaaS), which have gone to the VC trough four times since the company was started in 2008, have gotten what appears to be their first real money to grow on: a $12 million B round led by Devonshire Investors, t...