1 / 18

Putting middleware in perspective: 12 lessons learned [RTR Conference ‘99]

Putting middleware in perspective: 12 lessons learned [RTR Conference ‘99]. Charles C C Brett President C3B Consulting Limited & President The International Advisory Board MIDDLEWARE SPECTRA & FINANCIAL MIDDLEWARE SPECTRA (www.middlewarespectra.com). 12 lessons learned - drawn from:.

asher
Télécharger la présentation

Putting middleware in perspective: 12 lessons learned [RTR Conference ‘99]

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Putting middleware in perspective:12 lessons learned[RTR Conference ‘99] Charles C C Brett President C3B Consulting Limited & President The International Advisory Board MIDDLEWARESPECTRA & FINANCIALMIDDLEWARESPECTRA(www.middlewarespectra.com)

  2. 12 lessons learned - drawn from: • C3B Consulting assignments • MIDDLEWARESPECTRA • with (amongst others): Swiss Bank Corp Credit Suisse First Boston Charles Schwab Credit Suisse VPC (Swedish Clearing) CME CARIPLO Lloyds Bank Reuters Posten (Swedish Giro) … Nova Gas Wells Fargo S.W.I.F.T. SIMC SIAC Swiss Life Telekurs PeopleSoft FedEx Chase Manhattan ... US D of Transport Motorola Holiday Inn PG&E KNE Bay State Gas Swissair Renault Thyssen Informatik Carleton University …

  3. And you thought 5+ database vendors was too much choice …. • Yes, there really are 225+ middleware vendors … and seemingly more every week (even Microsoft is joining the party, sort of ...) • This translates into multiple 100s of products across at least 10 different categories • These vary from the architectural (DCE, CORBA, etc.) to the minimalist (as in JVMs) to the ‘big boys’ (TIB, MQSeries, RTR, etc.); but most have <$10M in product sales • Understanding the (any) differences is a constant challenge

  4. #1: Good middleware is invisible • The better middleware works, the less you notice it • Conversely, the more you have to think about it, the less productive it is • Invisibility brings its own challenges (who knows what is going on where?) • Transparency encourages forgetfulness (remember CICS, RTR, …)

  5. #2: Create your own abstraction layer • Don’t become a victim of your vendor(s) • Minimize the places where you may have to change code • Middleware should be as ‘replaceable’ as any other component

  6. #3: Middleware should support your business • Too often middleware reflects the organization rather than the business • Middleware should assist initiatives, not obstruct them • Middleware may be easier for opening inter-business opportunities, (for example S.W.I.F.T., the Internet, Inter-company) rather than introducing internally • Use the integration AND the Web to drive/explain why middleware is needed

  7. #4: Think positive - plan for success • Think big (or long term) if you want strategic success • Thinking small produces small results • Think long as well as short • Middleware is not another spread sheet, it really is complex; do not underestimate this • It may look easy (for example queuing); that does not mean people want to understand it • Your first implementation is always modest and does not represent what you will do if it is successful

  8. #5: Ignore the transactional dimension - and expire • Transactions are the key to every business; ignore the implications and watch your Orders (or Invoices or …) behave like one-way white rabbits • Understand whether and where you can exploit Explicit TP, Implicit TP and Optimistic TP • Business processing is changing - the Internet and inter-business are driving whole new approaches to ‘long-running’ transactions • Real time has its place, just as much as the ‘time divorced’

  9. #6: Middleware results are cumulative • Middleware allows you to focus on the application: in the past too much of development resource was focused on solving the implementation issue (rather than on the application); middleware - which is believed in - reverses this • If you do not believe you will constantly undermine your potential success with point solutions

  10. #7: Decouple in order to couple • Decoupling comes in many forms; the most usefulare: • of time • of platforms • of development • of management skills • etc. • Decoupling allows: • linking of ‘legacy’ as well as ‘modern’ applications’ • reduction of traditional coupling overheads

  11. #8: Interfaces are where the problems occur • “Experience — and not only ours — shows that when something goes wrong it will be at the interfaces where it goes wrong. The advantage of building your own (middleware) is that you can know what and where it has failed.” • Interfaces are where the value is added • Underestimating the potential for problems - technical or management - undermines credibility at all levels (from Executive to humble developer)

  12. #9: Infrastructure change is gradual, not instantaneous • It is extremely difficult for large, complex organizations to replace infrastructure • Few organizations want to invest in infrastructure • The decision to invest usually only come comes once the lack of one has become too obvious for management to overlook • Implementing infrastructure change is as much about patience as action (and the ability to ‘ignore’ technological changes is often an asset)

  13. #10: Make sure you can manage your middleware • Middleware without management is like an army without officers: • who knows what is going on where? • do you know if there is a problem? • can you fix it remotely (or at all)? • There are relatively few options today • Middleware management will itself depend on middleware

  14. The 11th lesson: ask if you need middleware? • Third tiers are an unnecessary addition • Centralization is looking increasingly ‘re-attractive’ • Complexity compounds cost; simplicityreduces cost • BUT: know thyself and organization before attempting this

  15. #12: middleware is not sticky (yet) • Conventional wisdom suggests that middleware should be like a ‘virus’: once installed, it should spread • Practical experience/research indicates this is not the case (yet); different projects buy different middleware • Individual middleware products have yet to acquire the ‘stickiness’ required for long term success

  16. Middleware works • “After all we have proved — in the demanding arena of financial processing — that asynchronous solutions can work. Now we are looking to others to carry the middleware burden as we concentrate on our business.” • “Our final lesson is that investing in middleware does work.“ • “By separating the pieces and linking them, the old and the new can be reused and combined. As such, middleware is potentially a golden key (if you can find the right lock).” • RTR

  17. MIDDLEWARESPECTRA & FINANCIAL MIDDLEWARESPECTRA • Resources available at www.middlewarespectra.com • Past analyses, from 1993 • Vendor database (225+ vendors listed, by category) • Collections (vertical, by technology/approach, contents in 10 Collections) • etc. • All the above are available (updated quarterly on CD) for Intranet use

  18. MIDDLEWARESPECTRA & FINANCIAL MIDDLEWARESPECTRA In the USA: PO Box 303168 Escondido, CA 92030, USA Tel: 1-800-933-5997 Fax: 1-619-432-6560 In Europe/RoW: St Swithun’s Gate, Kingsgate Road Winchester, SO23 9QQ, England Tel: +44 1962 878333 Fax: +44 1962 878334 Email: spectrum@middlewarespectra.com WWWeb: http://www.middlewarespectra.com

More Related