Larry Turley, the president of Ron Turley & Associates Inc (RTA), explains that right now his people are nearly 100% COBOL, but eventually he thinks it will switch over to mainly Java. Maybe not during his time as president at the company, but it will likely happen.
In the meantime, Turley and his COBOL developers are finding success implementing Java functionality with a COBOL modernization platform—isCOBOL Evolve from Veryant—that lets them write their code in COBOL, but deploy their apps in Java. RTA had been using ACUCOBOL as their development platform for over 20 years, but when that company was acquired by Micro Focus, some of the changes made them feel it would be better to take a look at what other options were available.
According to Turley, there aren’t that many options for PC developers using COBOL. There’s still a lot of support for the mainframe and midrange folks, but when it comes to a strictly PC-based clientele—which is RTA’s bread and butter—there’s just not much support.
COBOL does not have a reputation for being as Web-friendly as Java or .NET languages. So it follows that there’s a lot more focus on these newer languages. And even a 30+ year veteran of the COBOL wars like Turley has to admit that being Web-enabled is a huge advantage in today’s application development environment. In fact, building Web-based applications is the single biggest factor driving Turley’s decision to start deploying in Java.
According to Turley, Web services are definitely going to be a piece of that. He says that, “The hope is that we will have a lot of service-based interactions. Some of those will have to be developed as we go.” He plans to build out Web services as clients need them for particular purposes and use those experiences to build a library of practical reusable Web services.]]>
His recent book on SOA governance, for example, brings together the work of important thought leaders, who provide perspectives on governance – no doubt one of the essential aspects of true SOA. The new book discusses the ways of creating ground rules for services sharing.
To find out more about SOA governance issues, SearchSOA.com recently spoke with book editor Erl as well chapter author Anne Thomas Manes. They discussed things learned while composing the book, including the trending adoption curve of SOA governance, so-called Agile governance and the looming governance tasks of cloud computing. Check out their Q&A on SOA governance.
As a key figure in the development of SOA, Thomas Erl’s work has often graced SearchSOA.com’s pages. His writing is essential in that it has come to characterize many of the best practices of SOA field workers. That means effective strategies for SOA governance policy, practical patterns for sizing and sharing of services, and more. As we noted before, these are useful as references. Many services’ first principles have stood the test of time.
As examples of how ”the fundamental rules apply” check out Erl’s earlier work on SearchSOA.com, including his work on the Service Facade pattern that kicked off a series of SOA Patterns of the Week and the groundbreaking SOA Advisor series that looks at Business analysis and SOA.]]>
I found Bennioff’s assertions about the future of enterprise computing both entertaining and inspiring, but a little bit vague on the details. He was absolutely right about a lot of what he was telling the enterprise marketers to do. We need to be more open, more democratic, and better connected. I was really impressed by his vision for Toyota Friend, a private social network for owners of Toyota automobiles that lets the cars and their owners interact on a somewhat personal level. (Bennioff’s answer to IBM’s Volt?)
But how are those goals going to be realized? After the keynote, I got some answers from Salesforce VP Peter Coffee, head of platform research. ”Everyone knows that when the CEO asks what’s going on with the cloud, you better have an answer,” he told me, “Now, the same is going for social networking.” He cited marketing examples like Pepsi Refresh and Toyota Friend as potential differentiators that make social networking an imperative.
From the technical side, Coffee filled me in on three important points about the new Chatter system that’s enabling networks like Toyota Friend. First, he said that Chatter is not just a social networking app that can be deployed behind the firewall. According to Coffee, Chatter adds social networking functionality like feeds and profiles to existing enterprise applications.
Second, Coffee assured me that “Chatter is not a walled garden. Anything with an API can participate in Chatter interactions.” That means if your server monitoring software (for example) has an output API, it can potentially warn you proactively about common situations before they turn into big problems.
Thirdly, Coffee explained the new messaging model that Chatter is based on. According to Coffee, Chatter breaks down the barriers that currently exist in most organizations between documents and messages. Chatter has a content library with versioning management that employees can link to in an update similar to the way that they would on Facebook. But instead of going out to the entire organization, the update goes out to others who are following the project/customer/document/tags/whatever that are associated with that update. It’s supposed to make creating interoffice communications a similar experience to posting on Facebook or Twitter, which people already like to do.
Coffee claims that people demonstrably prefer this type of communication, when it’s properly implemented. He warns against allowing a social network to become just another silo and posits that one of the important keys for successful service integration is enabling abstract entities like accounts and documents to start conversation threads, using complex event processing in the background.]]>
Developers preparing work for operations have always been admonished not to ‘throw it over the wall’ but that has not naturally evolved into a true dialog with system admins that oversee the data center.
It has been discussed in relationship to cloud computing, but it remains an object of attention for the classic data center as well.
Noted Agilist Scott Ambler has counted effective links between developers and operations as a major goal for many years. At IBM he has worked with others to incorporate such best practices in frameworks and tools.
Tools are important said Ambler, agile development practice leader for IBM, when we caught up with him at Innovate 2011 event in Orlando, Fla., but he added that collaboration and communication are truly key. Dialog is needed, he said.
The noted Agile evangelist Ambler points out that agility can stall if quickly developed apps conflict with an ops department’s best practices.
“So many project teams run into trouble when they don’t talk with the ops people. A lot of developers don’t understand the needs of ops and their ways of doing things,” he says. “There is a gap, and it runs both ways.”
“Developers find ops won’t support the technologies that the teams have used. They won’t put up the servers. It’s a surprise.” It should not be, he said. “If you had taken the time to [meet] three months earlier, you wouldn’t get that surprise.”
Among projects Ambler has worked on at IBM is a process framework called Disciplined Agile Delivery. Elements influenced by this framework have been appearing in IBM Rational tools.
”We’ve baked in [DevOps] from a forward perspective and a reverse perspective. From a forward-looking point of view, you need to talk with ops people on a regular basis, so you know about their release windows, for example,” he said. For the reverse point of view, in diagrammatic descriptions, ops’ defect reports can be automatically fed back to development.
“This is such a common sense thing, you’d think it always would be included as a explicit part of the project,” he said. Ambler suggested better developer communications with operations helps ensure that the agile team members are good citizens.]]>
He cited some examples of reuse related savings for the Volt, estimating that 90% of the software developed for GM’s conventional engines was reused on the Volt. Moreover, 60% of the HVAC software was reused. Furthermore, Volt has a reconfigurable LCD display for its instrument cluster, he said, adding that it benefits from 90% reuse of software components from a conventional cluster.
Reused components have well understood metrics that allow for “more predictable processes and planning,” according to Bolander. It is ironic, he noted, that rote reuse can serve to free-up developer time that can then be concentrated on innovation.
“Our vehicles are differentiated more and more by software capabilities,” said Bolander. Interaction between software engineers and automobile systems engineers is now a daily fact of life, he said.
Figure 1: At IBM’s Rational Innovate 2011, Bill Bolander, Technical Fellow, General Motors, featured the Volt as an example of successful software reuse. A model hooked up to an electrical recharging tether was on display.]]>