Notes by Scott Shipp, edited by Tamara Marshall-Keim
CORBA to Web Services Migration Using Model-Driven Approaches and Offshoring
Georg Huettenegger, Credit Suisse
Huettenegger discussed challenges and lessons learned from migrating one of the world’s largest and most successful CORBA SOAs to a web services SOA.
Credit Suisse is an integrated global bank. It delivers all the possible services that a bank could offer. Credit Suisse employs more than 45,000 people from 160 nations.
The current Credit Suisse SOA is “nice, yet limited.” Where it is headed is not good. It has over 2,500 CORBA service operations, there are 20–30 Mill CORBA calls per day, and there are about 400 consuming applications. With such a large scale and with such widely distributed employees, maybe Agile is not the way to go.
Key challenges to the migration:
- The general operating M.O. is “managed evolution,” but this is not fast enough for CORBA as it exists. It would take decades.
- Some services were designed over 10 years ago. They were v1.0 and have not changed.
- Migration also does not provide a business benefit.
- There are sweeping cost cuts, so the migration project must be seen as a “must.”
- They had a mainframe-centric PL/1 infrastructure.
- Performance was a high priority. If you care about performance, REST or SOAP is a tricky and difficult starting position.
- They had to engage a vendor for four years.
- Set a goal for four years
- Included all stakeholders
- Knew that they must set successful milestones that could be delivered as often as possible. They wanted to go as quickly as possible and keep it going.
They needed IBM to develop new features for IBM products, and Heuttenegger gave a short overview of this.
The CORBA vs. Web Services Performance Challenge: In a fifth pilot, WS was on average 95% slower. After a full round of optimization, WS was only 14% slower. Part of the problem was on the client side—in their case, mostly WebLogic.
Then they found other unexpected infrastructure challenges:
- Oracle WLS JAX-WS SOAP parsing was too slow. They needed to prove the issue and possible solution to Oracle.
- They found functional bugs in the existing CORBA implementation; there were incorrect characters in the database.
- A new security solution did not work with just the UAT mainframe time being set to the future.
Migration options: They could make web services appear as CORBA. This was the cheapest migration but carried huge technical debt. Or they could migrate based on the newest standards. But this was more or even most expensive. Only about 10% of all existing services adhered.
Another aspect to consider was how to migrate services owned by a collective of 2000–3000 IT staff.
- Option 1: Too expensive if done by the current organization.
- Option 2: Generate as much MDA as possible, but this was more work than expected.
- Option 3: Use an offshore migration factory for the remaining manual work. This was an ideal offshore target and required simply rewiring.
How to insure success in your migration factory:
- Communicate. This is the only option. Tell the facts, be open, and move forward.
- Make sure that it works. There are some justified concerns. Some services had 300 possible request/response cases.
A plus: the factory got the migration going, with constant progress.
Along the way… What hit them most was the exception handling. The second largest problem was existing bugs. Nevertheless, they achieved the migration to some degree. And they have an upcoming Java platform upgrade that will be coupled with the final migration.
Keys to success
- Top management support, especially from the CIO and Chief Architect
- Many milestones to monitor progress
- Kept communication going to “keep [their] story straight”
Recommendations: If your migration is large…
- Be clear about why you need to migrate. Have hard reasons and a real business case.
- Invest time up front to understand exactly how people are using the current offering.
- Consider what improvements can realistically be achieved and how. Be sure it is realistic for cost and time.
- With big migrations, NON-functional requirements are key, and you need an enterprise solution.
Credit Suisse will be done in 2015–2016. Consumer migration will pick up in 2015. But new developments like REST and mobile are gaining steam. They are planning co-existence, and with IBM as their vendor, they have a better vendor situation.
Understanding Reference Models and Reference Architectures
Christopher Armstrong, Armstrong Process Group, Inc.
The reasons for this talk:
- To address the lack of consensus about what reference models and reference architectures are
- To discuss how reference models and architecture are used
- To add on some architecture/solution building blocks (TOGAF)
- To review the conceptual metamodel representing these concepts
A little bit about APG
- Member/contributor to UML, SysML, SPEM, and UPDM at the OMG
- TOGAF and ArchiMate at the Open Group
- Sparx Systems Value-Added Reseller
- IBM Advanced Business Partner
- Reference model: a division of functionality into elements together with the data flow among those elements
- Reference architecture: a reference model mapped onto software elements that implements the functionality defined in the reference model
- Reference model and reference architecture are not used carefully in most literature.
- “Typically generic reference architectures provide an architecture team with an outline of their organization-specific reference architecture that will be customized for a specific organization.”
- OASIS reference model for SOA [SOA-RM] provides a common language for understanding the important features of SOA. It does not address the issues involved in constructing, using, or owning a SOA-based system.
Presentation link: http://resources.sei.cmu.edu/asset_files/Presentation/2014_017_101_90458.pdf
Integrating Enterprise Architecture
Voytek Janisz, Progressive Insurance
This talk is about a practical approach to integrating enterprise architecture. Progressive started this work about two years ago and continues today. Progressive has a large enterprise.
What is enterprise architecture? There’s a theme in different definitions: principles and methods. Enterprise architecture deals with the scope of things, particularly the entire enterprise. It deals with business architecture as well as technology architecture. Current state architecture is a description of architecture as it is. It is discoverable. Target architecture is a description of a desired future state, particularly where a certain level of agreement has been met about how to get there. It is not discoverable but can be described. You can build a plan around getting from the current state architecture to the target architecture.
- One of the leading providers of car insurance
- 3000 IT personnel
- 100 architects
- 25 architecture domains
- 5 architecture boards
- 800 applications, loosely speaking (architecturally significant components of the system)
- 400 architecturally significant projects (projects that consciously or unconsciously change their architecture)
- Evolution in silos without consideration to the wider organization
- Not well-described systems
- Inconsistently described systems
- Descriptions scattered across the enterprise
- Projects must “start with the archaeological dig”
Architecture definition was one way to deal with the challenges. They used the TOGAF architecture methodology as a guide to assess the current state architecture. They found that they had to enhance some processes more and focus less on others that had already attained some level of maturity. So they deposited into templates from TOGAF customized by what worked for them.
Gaining formal business approval of the target was very important, and they received the promise for funding. The architectural work then entered the work prioritization funnel. Finally, it was implemented.
To create their Enterprise Architecture Repository, they started with a SharePoint site. Over time, they developed a set of catalogs. What were the building blocks that they wanted to use in architectural descriptions? The real breakthrough came when creating models using Sparx. It had three key features: it supported ArchiMate, allowed sharing, and allowed a database back end. This allowed them to think of architectural descriptions as data that could be mined, queried, etc.—an EA repository.
For the metamodel, they initially thought that by freeing employees to create models, the enterprise models would naturally emerge. That produced chaos, and they could not merge the models. They realized that they needed to choose focus areas, including business process, application components, nodes, and artifacts. They have now built 500 diagrams, with 17,000 connections between them, based on these elements.
What does this allow? It allows them to understand what business processes they have, which apps support those business processes, and which technologies support these apps. Also, they have “data stewards” that gate keep what goes into the EA repository. To change, add, etc. the names of a component in the metamodel, the data steward performs facilitation of impact analysis.
How do you keep the EA repository fresh and in-sync with the organization? They think of it like layers of an onion. At the core is the metamodel. The layer around it is composed of the Architecture Services Team and Data Stewards. The layer around that is composed of the Domain Architects and Architecture Review Boards. And the outer layer is the architecture community.
They learned a lot while establishing the framework and a ton more while actually using it.
- Have a goal and know what you want from the architecture for today or tomorrow. What short-term benefits do you need? In their case, they wanted the benefit of delivering solutions faster. Second, you need political capital, so you should deliver value quickly. You cannot take two years to develop an architecture metamodel because no benefits will be seen in that time period.
- Be mindful about how much you can manage.
- Build on the existing foundation if possible. Don’t try to change everything right away.
- Establish a taxonomy, that is, the language, common building blocks, etc. Try to use the same language that your stakeholders will use. The taxonomy will be used across IT disciplines.
- Establish information ownership and governance. Put in controls over change of the fundamental building blocks of the architecture.
- It is about information, not the tool.
- It’s also about people. Nobody likes change. Or they say they like it as long as it is someone else who has to change. Don’t just create job objectives. Make it personal for people. Communicate, communicate, communicate. Describe how it will be helpful, personalized to their context. They will become advocates.
Presentation link: http://resources.sei.cmu.edu/asset_files/Presentation/2014_017_101_89631.pdf