Feb 19th, 2009
As I mentioned in a previous post, last week I attended to the Eclipse Banking Day in London. It was an enriching experience for me, not only in terms of speaking in a foreign language in front of large crowd but also seeing what other financial institutions are doing with Eclipse. I also met great people, during and after the event, so, who could ask for more? It was a really great event!
Most of the presentations are now available on the event wiki page. I encourage you to take a look to some of them. Anyway, here there are some few personal thoughts about the presentations:
- Mike Milinkovich shared with us the Eclipse Foundation vision towards collaborative software development of tomorrow. He explained that in 3 years banks will collaborate on a common platform, where Eclipse could play a key role, and therefore banks will be able to focus all of their possible energies on what really provides them a competitive differentiation. I really wish it happens, but even though we have started seeing some proposals/incubators projects, like Financial Platform or Open Financial Market Platform, I believe we will spend a few more years before it becomes mainstream. Hopefully I’m wrong!
- It was also great to share a picture slide with Mike. The maturity model for OSS adoption is a great indicator of OSS engagement, not just for ISV’s but also for enterprises.
- Mike also introduced e4, the next generation of Eclipse, and its 3 key architecturals goals: Eclipse platform as services, modeled and declarative UI, and SWT for the web. Related to the last one, have you ever wondered how the Eclipse IDE could look like if it was a browser-based? well, then take a look at this post. Sounds interesting, isn’t it?
- Neil Bartlett did a great talk about OSGI. I liked the Stackless Stack reference.
- Damm, I missed Tas Frangoullides’s presentation about MDD and SOA at Barclays. For what I have seen on the slides, it sounds like a really interesting initiative.
- Miles Daffin, from Morgan Stanley, talked about provisioning in a large environment and some really strong installation policies. This is a great topic, because most of the big enterprises share the same requirements from the IT security guys, albeit we usually don’t discuss them in public: no downloads from Internet, no unapproved software installations, … So Miles’s talk about how they solved these requirements was really worth. And I totally agree him regarding provisioning: “Eclipse is not designed with enterprise users in mind”. So … lots of work for the P2 folks!
- Jeremy Nelson explained J.P. Morgan’s OneBench platform for trading applications based on Eclipse RCP. It was really great, but … wish he had included some pictures about the platfom.
- Sven Efftinge‘s presentation was about DSL frameworks and tools. He introduced the Eclipse modelling stack and he showed a real external DSL implementation using TMF Xtext and GMF. There are few DSL real examples that becomes public, so it is always a pleasure when someone explains one of them in a event. These guys from itemis are doing an incredible job.
- And the last one, Ferran Rodenas talked about la Caixa’s software factory approach using Domain Specific Modeling Languages. His talk was … well, we could summarize it as he did what he could! 🙂
And that’s all folks. Any other attendees would like to share their thoughts?
Jan 18th, 2009
As I explained in a previous post, the last year I have been involved in a renewal process of all of our application development tools. One of the first things we did when we started the program was to apply the most fundamental lean principle: eliminate waste. To lean thinking, waste is anything that does not create value for a customer. For those of you who are not familiarized with the lean principles, I recommend the “Lean Software Development: An Agile Toolkit” book. In this book, Mary and Tom Poppendieck translated the seven wastes of manufacturing identified in the Toyota Production System into the seven wastes of software development: Partially Done Work, Extra Processes, Extra Features, Task Switching, Waiting, Motion and Defects. In this entry I would like to explain some of the problems we have encountered while trying to eliminate waste and some lessons learned.
The first waste we tried to eliminate was the extra processes. In other word, we tried to eliminate paperwork that does not means adding value for our users or for our organization. In our case, this task was not related to the development of our tools, it was about eliminating extra processes that were embedded in the tools we developed which forced our users (developers) to execute some unnecessary processes. This action produced some surprises, since near the end of the development, in one of the latest functional demos, there was a crisis moment. Some developers reminded us an essential process they were following in the old tool: they defined the batch programs in a product repository. This process was removed deliberately, because it does not provide any value, so it was a surprise for us that our users asked for this. When we asked them why this process is necessary, they answered that they did not know, but it was something they used to do because someone told them that they must do this task. “Is this useful?” we replied. “No, but we must continue doing that because … we must do that”. Wow, it remembers me the monkey experiment. Obviously, and despite the laments of our users, we did not add again that process. So lesson learned: in order to eliminate waste you need to break the status quo, you need to break the corporate culture.
The second waste we tried to eliminate was the extra features, because this was one of the biggest mistakes we did in the past in other tools. Some years ago we started developing a new tool and, using the usability argument, we added a lot of features that lately nobody used. Some of the hitches you may suffer adding those features are that your code-base grows uselessly, increases maintenance costs and makes future developments more complex. This must not be a big problem if users really need these features, but why must we maintain them if they are not being used? Users, moreover, feel that the tool is more complex, so your usability argument disappears, and they reproached us that we are not focusing on what it is really important for them. Now, I am proud to say that our tools have less features, but, at least, the ones we implemented are really used. So two more lessons learned: 1) more features does not mean better tools; 2) usability does not mean more features.
I am going to stop here. I am sure most of you who have tried to eliminate waste have found these or similar problems. But I do not want to conclude this entry without explaining one of my latest lessons learned. It is not strictly related to lean thinking, it applies to software development in general, albeit it could only apply to some organizations. Sometimes, I believe it is better not to explain that you are using an “x” methodology, or to intensify your position saying that you learned those practices from whatever methodology. Sound strange, isn’t it? But I have discovered that lots of developers hate the words “methodology” and “process”, and they have adverse reactions when they hear them. I find easier to explain practices without any reference to the original methodology. Lots of times, using the common sense is better to prove the goodness of a practice. And if it does not sound good, perhaps it does not match your organization. OK, maybe I am generalizing. In every change process you will find resistance, so perhaps if it does not sound good it is because fear. So, my last lesson learned: use common sense, do not arbitrarily adopt new practices.
Dec 22th, 2008
After the success of the Eclipse Banking Days in Frankfurt and New York, the Eclipse Foundation hast just announced the Eclipse Banking Day in London on February 12, 2009.
Eclipse Banking Day is a day-long event for senior technical developers, architects and managers in the finance industry to learn how to better leverage Eclipse technology and the Eclipse community as part of their development strategy. The event will focus on three themes:
- Eclipse as a platform for application development;
- Leveraging Eclipse modeling technology for data exchange; and
- Collaborating with the open source community.
Attendees will have the chance to hear speakers from leading financial institutions and experts from the Eclipse community.
It is not a secret that Eclipse is being used by some of the major banks and financial institutions around the world. Well, as it could not be less, we are also using Eclipse, both as a tools integration platform and as a branch teller workplace. Some days ago, Ian Skerrett (Eclipse Marketing Director) asked me if we would be interested in sharing our experience with other banks. So … we decided to accept the invitation and I’m going to present at the Eclipse Banking Day in London how we are using Eclipse at “la Caixa“. Despite the below pompous abstract, I think it will be an interesting presentation.
Repository Based Application Development Environment for Banking Systems
“la Caixa” is currently the leading savings bank in Spain and the third largest financial entity in the country. With a large network of more than 5.500 offices, more than 8.100 automatic cashpoint machines, a staff of more than 26.000 employees and more than 10,5 million clients, ”la Caixa” has positioned itself as a leading entity and referent within the Spanish financial sector.
In this talk, we will explain how “la Caixa” is using Eclipse to create a repository-based application development environment that successfully empowers its +1000 developers to create first-class custom enterprise banking applications in a fast-changing market. We will take a brief tour of “la Caixa”‘s enterprise architecture and we will take an inside look at some custom Eclipse plugins built at “la Caixa”. We will describe how using a collaborative environment, visual designers and code generators “la Caixa” allows its developers to create rapidly all the software components, from web UI to IMS-PLI-DB2 transactions, but also archiving software reuse across the whole organization and enforcing governance in an unobtrusive way.
This presentation will also explain briefly how “la Caixa”‘s 24.000 tellers are using Eclipse as a branch teller workplace. We will describe “la Caixa” bank teller evolution, and how using Eclipse it is possible to integrate in a common workplace from a custom legacy UI render to a modern web UI.
If you are interested in attending, you need to pre-register (early, space is limited!). There is no cost to register but you must work for the financial services industry.
Hope to see and meet great Eclipse enthusiasts there! I will try to share my thoughts on the conference after the event.
Dec 8th, 2008
Recently, I have been involved in a major IT program, framed on a high demanding business strategic plan, which aims to renovate all of our core banking system. One of the program’s first steps was changing our IT organizational and governance structure, the enterprise architecture, the application development tools and the software development methodology.
Although my responsibility in this program only relies on the application development tools, as one of the PMO leaders, I was able to follow closely the rest of the items. One of the topics that I was specially interested on was the software development methodology, because among other things, before the program, it was one of my responsibilities, and, after the program, it will be, again, my responsibility. The truth is that I had high hopes for change (perhaps influenced by the “Yes, we can!” slogan), but the fact that they came to conclusion that we need another waterfall methodology, perhaps a bit stricter than the one we use today, disappointed and frustrated me.
But please, that nobody misunderstood me. I deeply respect the work and decisions of my colleagues. I have had the opportunity to explain my thoughts. I gave them some books on the topic. I tried to influence the people who had the task to define the new methodology in order to introduce more innovative methods/process/practices of software development, but, maybe, being too innovative in a very classic environment doesn’t helped me. I think that changing the software development process in a big organization requires lots of effort, education, very slow and gradual steps, …, and I do not want to miss this opportunity, I believe that now is the moment to do that, taking advantage of the whole changing program. Well, at least, now some people knows that there are more life after the waterfall model, there’s a gray scale between white and black. 🙂
As I’m a bit nonconformist, I tried to find out which were the reasons behind that decision. So I decided to ask some developers and project managers to get an exact idea of what they think/know about software development methodologies. Although most of the answers were what I expected to find, I also found some interesting frustrating observations. I want to share with you some of them:
- Most developers and project managers are unaware of the existence of another methodologies, and they do not have any interest in learning them. Methodologies and process are something bored and do not provide any value to what they are doing actually. Although they recognize there are lot of inefficiencies in the way they work, they don’t want to change it. When I ask some of them if they follow our actual methodology, their answer is NO. “Well, at least, are you following any predefined process?” again, the answer is NO.
- Most project managers feel that a plan-driven methodology provides them more control over the whole project, that their projects are more predictable. But when I ask them if their projects are on time, most of them recognizes that NO. They also doesn’t have/use information from previous projects in order to estimate or improve the next ones, every project is different.
- They see iterative / agility methodologies as a chaos, the wild west, where there isn’t any discipline. W00t? discipline and agile are not conflicting. XP, for example, requires high levels of discipline.
- Some people told me that waterfall methodologies encourages a comprehensive documentation. “Well, could you show me your last project’s documentation? no, we didn’t have time to write it. OK, doesn’t mind. Could you show me any documentation of any project you’re involved? no, we’re still working on it, you know, we’ve tigh schedules”.
- Some answers reflected the “We’re Special” syndrome: “Agile is suitable when you want to develop software for an Iphone, but not for financial applications” (paraphrased).
- Some project managers get annoyed when they must talk with their clients or stakeholders, they hate them (I believe this is a mutual feeling). Yeah, those evil people that everyday changes the requirements and doesn’t have any idea how hard is the software development process.
I also tried to analyze some projects, and, surprisingly, I discovered that most of them are short term projects (2-3 months). I expected longer projects, as corresponds to a waterfall process. So I ask myself if we are really using a waterfall methodology, or we’re using a masked iterative process?
How about you? Did you find these kind of answers in your company? Any ideas on how to address this situation?
Very nice summary of your experinece Ferran.
In my opinion a very good selling point of Agile methodologies is accountability. This accountability becomes specially appealing if your development team likes to work and the things they do but they feel frustrated by other departments. Agile methodologies are incredibly transparent and if there is inefficiencies in the processes they will highlight them in few weeks. The problem is that many people see a threat on this transparency as it would be fairly clear that they are not doing their job properly.
I imagine it must be very difficult to introduce this kind of methodologies in an organization like yours. In my experience, a good way to sneakly introduce Agile into corporations would be trying to convince people of give it a try on prototypes, proof of concepts or non-core projects. Small projects of few months. The probably will be successful and slowly the team member will start to appreciate the advantages of development transparency. At least after several succesful projects you would have a sollid argument inside your own company to try to promote the methodology further up.
Cheers.
Nice post, sad reading. I think that it is brilliant how you compare all their NOs to their SHOULDs, and how they fail to take the next steps based on the actuals.
Flick’ed and blogged a possible way to introduce changes, that may or not may apply to your situation.
Good luck!
Martin, Xavier, Thanks for your advice!
Interesting little survey… I’m not so used to working with big companies but I can assure you that there are problems in SMB too. Actually, the problem is more a lack of methodology. In a previous work experience, I worked for a startup whose CTO has been completely unable to come up with a product! He wanted to use an agile methodology but without exactly knowing what it was.. it ended up being a total mess with the specs constantly evolving and becoming more complex. As he was also a very poor team manager, he totally failed in building the required product and the startup collapsed… great experience but how frustrating!! This is why I now focus a lot on development methodology…
Thanks for this post…
Hi all,
I agree with Ferran (and the reason is not the fact that he is my boss 😀 ). In concrete I found very interesting his last analysis: Short term projects masking iterative processes. My personal experience about that issue is that classical (waterfall) projects are getting smaller and smaller. As a consequence of this,comprehensive documentation, good planing and other supposed features of classic methodologies are disappearing. They act as they have the control but they don’t. Ok, some feeling of “chaos” is arising, but there are lot of things to put the blame on and methodology is not present in their minds.
Regards
Andrés
Hey Everyone,
Excellent post!!! It gives a lot of insight as to needing some form of methodology
when it comes to development projects. I agree with Thibauld in that I have worked for
a company that crumbled because of the dis-organization of projects.
I appreciate the post.
Nice article…..I really impressed while reading your post…..Thank you so much , it will useful to every one….
Nov 27th, 2008
Steve Cook:
Cameron has been blogging about new features in our product.. In a recent post he used the term Explicit Design. I’ve been reflecting on this, and I like it. In software development we really do need to capture design data that is not just the code, but should be saved and versioned just like the code. What do we call it? We could call it “models” but “model” and “model driven development” are subject to so much historical baggage and methodology and terminology arguments. “Model” just seems to imply baked-in code generation and round tripping, when there is so much more that you can do with it: planning, verifying, testing, refactoring. We need new vocabulary that represents our ability to capture versioned design data at a more abstract level than the code without simultaneously implying the history of CASE.
I have to agree: changing the name doesn’t solve the root of the problem, but perhaps we start thinking in a different way.
Grady Booch has an interesting take around this topic area:
“Every interesting software-intensive system has an architecture. While some of these architectures are intentional, most appear to be accidental.”
Links:
http://www.informit.com/articles/article.aspx?p=471929
http://www2.computer.org/portal/web/computingnow/onarchitecture
– Bill
Bill, thanks for the link! A very interesting reading, a natural thing as it comes from Grady.
Some conclusions after reading the article:
-
We need to enumerate architectural patterns or styles, even if they come from accidental architectures. Something that I believe Grady is working on (Handbook of Software Architecture), and, with a wide aim, The Hillside Group.
-
Most architectures come from previous works (theft): bifurcations, scrap and rework. Although most of them are accidental architectures, they are inevitable and some of them could become useful in future systems, but only if we’re able to describe them as a pattern.
