Bespoke Software Product Factory   Peter Antman Niklas Hagen Björn Hällström
SubVersion Maven Eclipse JUnit eXtreme Programming SCRUM Product Owner Sprint Subscription Software Market 3.0
Software Markets <ul><li>Software Market 1.0 </li><ul><li>Pay for the machine
get bundled software free or roll your own
IBM </li></ul></ul><ul><li>Software Market 2.0 </li><ul><li>Pay for right to use software
Adapt to wrapped box
Microsoft and Oracle </li></ul></ul><ul><li>Software Market 3.0 </li><ul><li>Pay for the value software delivers
Assemble freely available parts
Linux </li></ul></ul>
Adapting to change
The Zero effect <ul><li>The connected net ->  the connected economy -> the connected people </li></ul><ul><li>The distance...
Cost of transaction almost zero
Information is free </li></ul>
The looking glass <ul><li>Open Source
The Long Tail
Karaoke economy </li></ul>
Open Source is the key <ul><li>Open Source is born with the net and is the engine behind the net
Open Source is a way to handle the “net-effect” </li></ul><ul><li>We can learn from open source
We can use open source
We can contribute to open source </li></ul>
 
Open Source economy
Commodification
Modularization
Standardization
Open Source Bussines <ul><li>Adding value on top of stack: because of </li></ul>Free BSD Linux Apache Linux/JBoss JBoss OS...
Tom O'Reilly ”Software is no longer the primary locus of value in the computer  industry. The commoditization of software ...
The Long Tail <ul><li>One size does not fit all
There is a market for diversity
57% of what Amazon sales was not available before Amazon existed </li></ul>
Where does Mogul fit in?
SubVersion Maven Eclipse JUnit eXtreme Programming SCRUM Product Owner Sprint Subscription Software Market 3.0 Customer
Karaoke economy <ul><li>A market dominated by indivuals with endless choice </li></ul><ul><li>In a surplus economy </li></...
...Karaoke economy <ul><li>Means hypercompetition for businesses </li></ul><ul><li>Copy-cats abound  </li></ul><ul><li>Sho...
No time <ul><li>…for doing things they are not (supposed to be) best at
Typical IT department spend 50%-80% of time on support and maintenance
Slows down time-to-market
Loosing customers and sales
Less profits
Smaller budget for development
…etc. </li></ul>
They need an agile appDevPartner <ul><li>A highly specialised partner in developing bespoke applications </li></ul><ul><li...
A Bespoke Software Product Company <ul><li>Based on a service model: </li><ul><li>Subscription to a production model that ...
Upcoming SlideShare
Loading in …5
×

The Bespoke Software Product Factory (2007)

1,275 views

Published on

A business plan for how to create a service company for building prodcuts based on the ideas of sotware market 3.0, open source and agile methods.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,275
On SlideShare
0
From Embeds
0
Number of Embeds
77
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • För att bäst förstå hur Mogul ska bygga sitt erbjudande måste vi titta på vilken verklighet våra kunder lever i och fråga oss: -Hur hjälper vi bäst våra kunder att lyckas med sina affärer?
  • Individanpassade produkter och tjänster Vi kunder vill ha allt mer individanpassade produkter och tjänster. Och eftersom teknologin gör det möjligt att leverera och vi kunder är kungar i överflödssamhället, vinner det företag som bäst matchar sina varor och tjänster med våra individuella behov.
  • Eftersom informationen vill vara fri och informationsinnehållet i varor och tjänster ökar hela tiden, blir allting allt lättare att kopiera. Livscykeln för en vara eller en tjänst blir därför allt kortare, vilket i sin tur tvingar företag att allt oftare lansera produkter och nya tjänster och nya features. Företag måste fokusera på att kontinuerligt göra det de är bäst på, nämligen att utveckla sina produkter och tjänster
  • Då har de inte tid att ägna sig åt sådant som inte är deras kärnverksamhet. T ex att utveckla applikationer och webtjänster. Undersökningar visar att en typisk intern IT-avdelning lägger mellan 50% och 80% av sina resurser på support och underhåll av den existerande applikationportföljen. Det betyder att det oftast blir tvärstopp eller enorma förseningar när de ska leverera något nytt. Och då tappar de kunder och försäljning. Förlorar lönsamhet. Får mindre budget för nyutveckling. Tappar ännu fler kunder och försäljning...
  • Partner Därför måste dessa företag skaffa sig partners som är specialiserade på att utveckla skräddarsydda applikationer Applikationer som tål snabb affärsutveckling utan att de blir underhållsbördor. En partner som kontinuerligt hjälper dem att utveckla nya features i befintliga applikationer eller nya applikationer.
  • Vi erbjuder våra kunder att: Abonnera på sprintar = ny funktionalitet som realiserar affärsvärden Betala för det du använder Utvecklingstjänsten/produktionstjänsten Support Vi skapar team som är små mjukvaruföretag Med egna produktionslinor
  • Renovation of software through (continuous) refactoring of older,”home made” and non-standardised parts by replacing them with standardised components and architectures. Mogul’s gentrification approach aims at building applications as far as possible based on standard products (mainly Open Source based products) and to move the commoditisation as far up in the application as possible. The goal is that only the unique parts of an application will need to be maintained and developed.
  • The Bespoke Software Product Factory (2007)

    1. 1. Bespoke Software Product Factory Peter Antman Niklas Hagen Björn Hällström
    2. 2. SubVersion Maven Eclipse JUnit eXtreme Programming SCRUM Product Owner Sprint Subscription Software Market 3.0
    3. 3. Software Markets <ul><li>Software Market 1.0 </li><ul><li>Pay for the machine
    4. 4. get bundled software free or roll your own
    5. 5. IBM </li></ul></ul><ul><li>Software Market 2.0 </li><ul><li>Pay for right to use software
    6. 6. Adapt to wrapped box
    7. 7. Microsoft and Oracle </li></ul></ul><ul><li>Software Market 3.0 </li><ul><li>Pay for the value software delivers
    8. 8. Assemble freely available parts
    9. 9. Linux </li></ul></ul>
    10. 10. Adapting to change
    11. 11. The Zero effect <ul><li>The connected net -> the connected economy -> the connected people </li></ul><ul><li>The distance between any point is functionally zero
    12. 12. Cost of transaction almost zero
    13. 13. Information is free </li></ul>
    14. 14. The looking glass <ul><li>Open Source
    15. 15. The Long Tail
    16. 16. Karaoke economy </li></ul>
    17. 17. Open Source is the key <ul><li>Open Source is born with the net and is the engine behind the net
    18. 18. Open Source is a way to handle the “net-effect” </li></ul><ul><li>We can learn from open source
    19. 19. We can use open source
    20. 20. We can contribute to open source </li></ul>
    21. 22. Open Source economy
    22. 23. Commodification
    23. 24. Modularization
    24. 25. Standardization
    25. 26. Open Source Bussines <ul><li>Adding value on top of stack: because of </li></ul>Free BSD Linux Apache Linux/JBoss JBoss OS X Google Websphere Support Subscription
    26. 27. Tom O'Reilly ”Software is no longer the primary locus of value in the computer industry. The commoditization of software drives value to services enabled by that software.”
    27. 28. The Long Tail <ul><li>One size does not fit all
    28. 29. There is a market for diversity
    29. 30. 57% of what Amazon sales was not available before Amazon existed </li></ul>
    30. 31. Where does Mogul fit in?
    31. 32. SubVersion Maven Eclipse JUnit eXtreme Programming SCRUM Product Owner Sprint Subscription Software Market 3.0 Customer
    32. 33. Karaoke economy <ul><li>A market dominated by indivuals with endless choice </li></ul><ul><li>In a surplus economy </li></ul>= Totally illoyal Zapping Customers <ul><li>Demand tailor made offers </li></ul><ul><li>Continuous improvments </li></ul>
    33. 34. ...Karaoke economy <ul><li>Means hypercompetition for businesses </li></ul><ul><li>Copy-cats abound </li></ul><ul><li>Shorter product life cycles </li></ul><ul><li>Companies need to focus on their core businesses, </li><ul><li>developing their products and services </li></ul></ul>
    34. 35. No time <ul><li>…for doing things they are not (supposed to be) best at
    35. 36. Typical IT department spend 50%-80% of time on support and maintenance
    36. 37. Slows down time-to-market
    37. 38. Loosing customers and sales
    38. 39. Less profits
    39. 40. Smaller budget for development
    40. 41. …etc. </li></ul>
    41. 42. They need an agile appDevPartner <ul><li>A highly specialised partner in developing bespoke applications </li></ul><ul><li>Applications that allow for swift business development and doesn’t become maintenance burdens </li></ul><ul><li>A partner that helps them to continuously develop new features </li></ul>
    42. 43. A Bespoke Software Product Company <ul><li>Based on a service model: </li><ul><li>Subscription to a production model that is able to deliver new business features in an ongoing cycle </li></ul></ul><ul><li>WYNIWYG: What You Need Is What You Get </li></ul><ul><li>For each project we create: </li><ul><li>A lightweight product company
    43. 44. An agile “assembly line” </li></ul></ul>
    44. 45. SubVersion Maven Eclipse JUnit eXtreme Programming SCRUM Product Owner Sprint Subscription Software Market 3.0 Customer Project Process
    45. 46. <ul><li>Traditionally, the same process control has been applied for simple physical product assembly and complex software development </li></ul><ul><li>Defined process control does not fit modern software development very well </li></ul>Simple vs Complex Processes
    46. 47. <ul><li>Requirements change
    47. 48. The market changes
    48. 49. Technology evolves and changes
    49. 50. End users expect new functionality and improvements - constantly
    50. 51. End users expect stable, working systems </li></ul><ul><li>Scrum is tailored for satisfying these needs </li></ul>“ Constant Beta” – Release early, release often
    51. 52. The four variables – defined process control <ul><li>Ideally, we want all of these variables to be set! </li><ul><li>High quality
    52. 53. These 1000 perfectly described functions
    53. 54. Delivery May 1st
    54. 55. Fixed price – total cost of 1000 SEK </li></ul><li>This is IMPOSSIBLE with complex processes!
    55. 56. The first that has to be let loose is quality...
    56. 57. The second is delivery date...
    57. 58. The customer can’t change his mind..
    58. 59. No one is happy! </li></ul>Time Functionality Cost Quality
    59. 60. <ul><li>In Scrum we lock all variables apart from the functionality </li></ul><ul><li>Thus we do guarantee: </li><ul><li>A certain quality
    60. 61. A certain cost per sprint (sprint subsciption)
    61. 62. The possibility to release early and often (each sprint produces a deliverable) </li></ul></ul><ul><li>But we don’t guarantee a fixed number of functions within each sprint </li></ul><ul><li>This process control enables the customer to change, add and reprioritize functionality between each sprint </li></ul>The four variables – empirical process control Time Functionality Cost Quality
    62. 63. The Service Model: Sprint Subscriptions
    63. 64. Sprint is the core unit of work Each sprint produces a working system that realises the business value the customer has expressed in the features that where part of the sprint backlog
    64. 65. Based on Open Source experiences <ul><li>Open Source inspired way to develop software </li><ul><li>release early, release often
    65. 66. involvment in a community
    66. 67. best pracitises
    67. 68. commonly used tools
    68. 69. deliver only what you need </li></ul><li>Open Source based stacks </li><ul><li>Modular stacks
    69. 70. Assemble commodity parts
    70. 71. Add value on top
    71. 72. No home grown systems
    72. 73. gentrification </li></ul></ul>Machine OS Database Application Server Application Application Stack Commodity Bespoke
    73. 74. ... and agile processes <ul><li>Scrum: how we manage the sprint </li><ul><li>continually translate business needs (values) into software features
    74. 75. prioritize expressed features
    75. 76. continually re-estimate work needed and needed work
    76. 77. measure delivered value through acceptance tests </li></ul></ul><ul><li>eXtreme Programming: how we work inside the sprint </li><ul><li>translate software feature into testable and implementable development tasks
    77. 78. continually realize business needs (values) as software implementations
    78. 79. evolving architecture
    79. 80. measure delivered value through unit tests </li></ul></ul>
    80. 81. A lightweight product company <ul><li>The application is embedded in a project process mimicking the one a product company usually maintains: </li><ul><li>Product /inception – from idea to realisation, or from an existing project to a fully transferred application ownership
    81. 82. Product Management – from features to implementable user stories and tasks
    82. 83. Product Development – from user stories and tasks to implemented and tested functionality
    83. 84. Product Maintenance – support and issue management, continuous maintenance of the software stack used by the products </li></ul></ul>Product Road Map Product backlog Product Release Support issues Product Management Product Development Product Maintenance Processes Product artifacts
    84. 85. The Assembly Line
    85. 86. Colaboration platform <ul><li>The portal exists to give all the product stakholders a common communication platform. Here clients meet with project managers, designers, developers, testers and stakeholders.
    86. 87. Throughout the product lifecycle it gives: </li><ul><li>transparency,
    87. 88. improves quality,
    88. 89. efficiency
    89. 90. traceability </li></ul></ul>Product Jira : Product and Sprint backlog, as well as Issue Management Subversion/FishEye : Version Management/Control Forum : Communication Wiki : Documentation Luntbuild : Continuous integration Acceptance Testing Time logging Collaboration Portal Dashboard portlets
    90. 91. The Project Process
    91. 93. SubVersion Maven Eclipse JUnit eXtreme Programming SCRUM Product Owner Sprint Subscription Software Market 3.0 Customer Project Process Development Process
    92. 94. The Development Process – best practices <ul><li>Open Source Software development </li></ul><ul><ul><ul><li>A proven, lightweight and well known set of tools
    93. 95. Reuse of open source modules
    94. 96. Knowledge transfer through code access
    95. 97. “Scratch your own itch”
    96. 98. Release early, release often </li></ul></ul></ul><ul><li>The software development culture from the UNIX world </li></ul><ul><ul><ul><li>Modularization
    97. 99. Small is beautiful (KISS) </li></ul></ul></ul><ul><li>Agile system development (eXtreme Programming) </li></ul><ul><ul><ul><li>Test-driven development
    98. 100. Process build to adapt to changes
    99. 101. release focused
    100. 102. quality control </li></ul></ul></ul>
    101. 103. SubVersion Maven Eclipse JUnit eXtreme Programming SCRUM Product Owner Sprint Subscription Software Market 3.0 Customer Projekt Process Development Process Tools
    102. 104. Best of breed tools (examples) <ul><li>Maven as a build framework
    103. 105. Eclipse and NetBeans as development environments
    104. 106. TestNG and JUnit for Unit-tests
    105. 107. Cactus and Cargo for integrations tests
    106. 108. Luntbuild for continous integration
    107. 109. Selenium for GUI acceptance tests
    108. 110. JBoss/Tomcat and Apache as server environments </li></ul>
    109. 111. The 11 principles <ul><li>Simplicity in design and code: create software that is easy to change
    110. 112. Don't overdo it (&quot;ta inte höjd…&quot;): do only what is really needed
    111. 113. Refactor mercilessly: strive for optimal design
    112. 114. Develop coding standards: communicate ideas through the code
    113. 115. Create a common vocabulary: communicate ideas about the code
    114. 116. Use test-driven programming: prove the code works
    115. 117. Use pair-driven design and problem solving: use collective knowledge
    116. 118. Collective ownership of code: spreads responsibilities
    117. 119. Integrate often: handle effects of new features
    118. 120. Use short iterations: take small controllable steps
    119. 121. Release often: have a tight feed-back loop </li></ul>
    120. 122. OpenSource Java Bespoke Software / Applications SubVersion Maven Eclipse JUnit eXtreme Programming SCRUM Product Owner Sprint Subscription Software Market 3.0 Customer Project Process Development Process Tools

    ×