Migration efforts can seem daunting, but upgrading legacy databases isn’t an impossible task. During the “Mainframe and Database Legacy Modernization” session at Red Hat Summit 2013 in Boston, Red Hat services delivery manager Emily Brand likened the process to peeling an onion.
“Every layer you pull off, try to remove the layers of the legacy,” she said Wednesday morning.
To get started, Brand recommended people begin with analyzing their current infrastructure and then think about the ultimate mission they are trying to accomplish. This is how one begins to map out a plan to make their goals a reality.
Brand said, “Ask yourself, what does your environment look like? Is it monolithic or do you have a bunch of scattered databases and applications?” She noted it’s difficult to move a project forward when there are multiple versions of everything.
Throughout her session, Brand touted the benefits of enterprise data services (EDS), saying the platform makes it easier to move to more modern middleware. She said an EDS can be a layer above databases that can integrate multiple data services or just be a layer between them.
It’s also important for people to standardize databases to the version they want, choosing as few as possible. Middleware, programming languages and SOA governance also need to be standardized, Brand said. The more stringent one is with frameworks and languages, the more agile developers can be within an organization.
There are, however, times when flexibility is key. By allowing for exceptions, one can maximize IT infrastructure, Brand noted, “Instead of being a maintenance machine, you can be a development machine.”
There are several benefits to modernizing legacy databases that make taking on what may initially seem like a scary migration effort worthwhile, even from an ROI perspective. Brand said some of them include:
- – Decoupled business applications from several sources
- – Isolated data layer
- – Companywide semantics
Don’t just work with the present in mind, perform work anticipating future needs. Everything should be able to talk everything else in a way that can easily be tracked, Brand said. This is because ambiguity can lead to unnecessary headaches. “Think 10 years down the road,” she said, elaborating that new employees will be forced to deal with the ramifications of whatever decisions are currently be made.
Enterprise demand for Mobile Backend as a Service (MBaaS) has been gaining traction, according to StackMob, a back-end technology stack for mobile applications. BaaS has been touted as an inexpensive method to improve scalability, flexibility, and security by the technology’s advocates.
StackMob recently teamed up with Rackspace, an open cloud company, to help capitalize on the trend.
“Enterprise for the first time is completely rethinking how they are developing applications, which is very exciting because as far as I’m concerned, this hasn’t happened before,” said StackMob CEO Ty Amell in an interview with SearchSOA.
Amell likened the innovation and growth in the mobile ecosystem to the Industrial Revolution.
“If you look at what happened back in the Industrial Revolution, there were standardizations and factories that allowed people to build things like never before,” said Amell. “Fast forward to today and we have a Tech Revolution… we have all of these BaaS providers with niche services, all providing great services and then we have APIs allowing systems to talk to each other. For the first time we have a standard service.”
Furthermore, Amell said the movement is something that won’t take several years to catch on and more to implement, rather he foresees it as a fast-moving market.
The growth should come as no surprise given that data from Strategy Analytics indicates that over the next five years, revenue associated with mobile workers using enterprise business apps will nearly double.
“Mobile workers have moved beyond just mobile email and messaging to include other collaboration apps such as conferencing, productivity apps such as content authoring, and business process apps such as CRM and even ERP,” said Strategy Analytics director of business cloud strategies Mark Levitt in a statement.
Do It Yourself (DIY) television shows have proven popular with audiences, but the same “I can save myself money by doing it on my own,” mentality that makes for good entertainment, may not be so amusing when it comes to OSGi server runtimes.
During his lecture, Ward talked about how those who enjoy DIY projects will like OSGi because it’s all about modularity. “It’s very easy to build a server runtime from a freely available piece,” he said. “OSGi makes it simple to reuse components, but do you want to do this?”
If an application architect decides to go the DIY route, there are several options to choose from. Among the platforms are: Eclipse, Apache, Aries, JBoss, GlassFish and IBM Websphere, explained Ward.
There isn’t a cut-and-dry answer to what features should be used. Just like the many aforementioned platforms, each scenario needs to be looked at independently.
Ward advised session attendees to ask themselves, “What do you want from your runtime?,” he asked. “You need to answer this question first. Is it a development stack for playing around with?”
Ward also advised people to consider the following:
– Do you want to learn? You’ll gain the most knowledge if you build it yourself;
– What kind of time do you have? You’ll make the fastest progress using a pre-built offering;
– Is it a small/medium reduction system with a small feature set?
Even though each situation has its own circumstances, there are some general rules to follow. Ward suggested that for those creating an application that needs a lot of features, building their own runtime isn’t a wise decision. He asserted that in such a scenario, developers should save themselves time and pick a pre-built runtime that offers the necessary services.
Another situation where building a runtime can also be a poor use of resources is when an application needs to run on three or more nodes. Again, Ward said this is a scenario where it’s better to fork over some cash. The combination of deployment, management, and monitoring will be big issues.
Ward’s closing piece of advice was this, “Mostly, pick an option that’s designed for your requirements. The number of people who don’t do this is crazy!”
For enterprise architects, taking an “out with the old, in with the new” mentality can be tempting when modularizing large legacy Java applications, but that could be a mistake. That’s according to Vineet Sinha of Cambridge, Mass. –based Architexa.
During a EclipseCon 2013 session March 26 in Boston, Sinha cited some pretty staggering statistics. Among them was one he attributes to IBM, which says up to 90% of a developer’s productive time is spent trying to understand code.
Devoting even half your time unraveling a mess of code can be daunting, admitted Sinha, but that doesn’t mean developers should try to reinvent the wheel. Rewriting code can be costly and time consuming. Instead, he offered some pragmatic advice that starts with building architectural maps. It’s not uncommon for team members to have different pictures of a project’s main components.
“Even if you have 100 developers, get the team leads into the same room,” Sinha suggested. Armed with old-fashioned paper, the participants should document the top components and connections between the components. “I’m essentially saying; try to get them to merge their ideas.”
This exercise helps make sure everyone is on the same page. “The first time we did it we split the things we agreed upon,” said Sinha. “We had a whole list of things we needed to think about the next time. One hour and we had that.”
Writing on a whiteboard may also prove beneficial in helping people understand a system. Sinha noted how people in his organization began to plan around what they saw on the board.
With everything clearly documented, the team will have a more central view and will have an easier time obtaining necessary information down the road. “If you are writing any new code, you are not putting it in the wrong place,” said Sinha.
While untangling the web of code implemented by someone else may seem like a thankless task, it’s important to remember what you are doing can be extremely difficult. Setting aside time on a regular basis, whether it be at the personal or team level, for fixing is also important.
Sinha offered another commonsense tip: celebrate your successes. Even the smallest victories are meaningful as they can be used as stepping stones towards long-term goals.
Want a challenge? Add the avalanche of enterprise mobile applications to DevOps teams’ already-daunting integration workload, Paul Kopacki says. He’s Sencha’s vice president of marketing, which just released a mobile app integration tool for developers.
Last week, Sencha Inc. of Redwood, Calif., released upgrades to its product line designed to make HTML5 development more simplistic. The company’s core offerings–Sencha Architect, Sencha Ext JS and Sencha Touch–have been enhanced to make it easier to quickly build HTML5 applications for any platform. A new touch bundle for mobile developers was also launched.
Among the key upgrades to the Sencha ExtJS product is a big-data grid. “There are many more data points people want to build into their applications,” Kopacki said in an interview. “Big-data grids are one of the things customers are asking for and we are delivering in this release.”
Financial data companies are among those who rely on the technology on a daily basis. One Sencha client used the technology to build an app for bond traders. The client company, which tracks a great deal of information, needed greater capacity to take the data and share it with its bond traders in a faster pace.
Online accounting software company Xero has also embraced the technology. The company’s CTO, Craig Walker, said a few years ago that he realized Xero wasn’t delivering a positive mobile experience. “Our experience had been with native development and we wanted to move to Android, etc. The mobile touch framework delivers a lot of functionality up front,” he said during an interview. “What would have normally taken us six to nine months took us three.”
While there has been some debate over HTML5, Sencha has a clear stance on the technology: It’s a big proponent. In fact, the company recently developed a copy of the Facebook app to show that developers, not HTML5, were the issue when Mark Zuckerberg abandoned the markup language last fall.
“Some people come to HTML5 from a web perspective and fail to see the power of HTML5,” said Kopacki. “If you come at it from an application development perspective, you use the right tools so that HTML5 is powerful, especially for business applications.”
While the debate over HTML5 is sure to rage on, at least for now, some companies are banking on its ability to quickly aid programmers as they integrate old systems with new technology.
Running through the history of computing is a quest for modularity. We curse it when it doesn’t work; we take it for granted when it does. Long ago, software engineers began to seek the equivalent of Lego bits, software modules that could be swapped much like bus boards on a hardware backplane. It’s been a long strange trip.
Modularity has gone through various stages in the modern era, with objects, components and, then, services, coming to take the place of Lego pieces in the software world. But, even in one of their (somewhat) recent iterations – that is, the services-oriented OSGi Service Platform – the mechanics software module interaction is not easy for developers or architects to master.
“Java Application Architecture” (Prentice Hall, 2012) by Kirk Knoernschild is one of the more probing books you are likely to find on this subject. Before the year past is very far past, I would like to take some time to discuss the book , as it is one of the better ones I have read lately.
The book has a straightforward principle, which is to provide guidance for those who might set out to design modular software. In Knoernschild’s terms, it looks at ways you can “minimize dependencies between modules while maximizing a module’s potential reuse.” This is, one, a major goal of middleware; and two, a long-time holy grail of software development.
While much of the book portrays garden-variety java problems, a fair amount of “Java Application Architecture” which is subtitled ‘Modularity Patterns with Examples Using OSGi’ also has a helping of OSGi know-how.
A conversation with Knoernschild disclosed that the book arose from an initial interest in uncovering how to leverage different layers of abstraction – to reach a deeper understanding of software architecture, and gain ease of maintenance. Composition of “Java Application Architecture” happened over many years, and there were discoveries.
“Along the way, the book morphed based on me learning more about how to design large software systems based on the Java system, with JAR files as the principle unit of modularity. Then, in the 2006 time frame, I discovered OSGi,” said Knoernschild, “I started digging into OSGi.”
He said he found the ideas of OSGi meshed with his own ideas about Java modularity in general. OSGi, for example looks at JAR files as the main means of re-use, treating a JAR file as a first class citizen. In the book, he explains how to take a monolithic application, modularize it and eventually bring it under the control of OSGi.
At heart, the issues Knoernschild addresses in “Java Application Architecture” are about dealing with complexity. Like Fredrick Brooks’ work, you could say Knoernschild’s effort is to separate the accidental complexity from the essential complexity. His thoughtful look at Java modularity is more than just tools and tricks – it is a foundational framework for thinking about problems of software architecture.
“Designing software is hard. It’s hard because breaking up the systems is so difficult,” said Knoernschild. OSGi’s detractors still argue that it, in itself, in fact, is too difficult. But experience tells us things are hard for a reason, and while the general drive of software is to make things easier, it is a daily battle to effectively simplify the complex. Knoernschild’s book, fights the good fight, and could become a valued companion at many developers’ bench tops. All and all, it is a brilliant breakdown on modularity.
Like ”cloud” before it, ”big data” is a nebulous term veiling some actual trends. Google and Amazon have been startling online successes, and much of their achievement seems to stem from massive amounts of Web-based data that they deftly correlate to create powerful views of the customer. Some people see the big data tent coming to cover sports marketing, pizza delivery and more.
But it is not just data at rest that is in question. The need for big data in motion is growing, viewers claim. For its part, middleware stalwart Tibco sees big data, coupled with event processing and fast messaging, as a route to greater market penetration.
“We kind of own the big data problem as it relates to real-time events,” Tibco’s Vivek Ranadive told SearchSOA.com on a recent call. He maintains that even common tasks like pizza delivery – granted, for national chains – will be affected by big data. “When customers inadvertently get cold pizza, the company can pick that up,” and make things better with a free pizza, a coupon or what have you.
“When you think about big data, it is about running twenty-first-century risk. The planet needs an ‘eventing’ platform,” said Ranadive, author of “The Power of Now” (1999) and “The Two-Second Advantage” (2011).
The Tibco event architecture plays a role in a recent user story on SearchSOA.com. Our site recently profiled shipping giant OOCL’s Matt Rosen who shows how challenging markets can be, and how pivotal well-managed technology is in addressing those markets.
Shipping companies were in a tough bind when the 2008 downturn struck, and the going was not easier when recession hit big European markets. OOCL’s performance outpaced competitors, and in some significant part due to Rosen’s application development team, which better enabled efficient business processes for the global shipper.
Among a host of technologies Rosen’s OOCL crew employed was an event processing engine from Tibco Software. OOCL’s habitat – the shipping industry – is among those that advanced middleware maker Tibco is counting on to take it beyond its Wall Street techno roots. – Jack Vaughan
A recent piece by Stephanie Mann looks at SOA design issues today. After over ten years of SOA, some best practices are still emerging. Among the notables Mann spoke with is Robert Daigneau. With stints heading development at both Fidelity Investments and Monster.com – he now heads the Application Development at Slalom Consulting – there are few who have seen more in the way of the evolution of services design patterns than Daigneau.
Daigneau touched upon a most-dreaded pitfall of SOA – here we call it ”boiling the ocean.” It is a sort-of top down approach that must enumerate a gazillion ”services” before writing a line of code. Practicality has move this approach from the top of SOA practices, but there is something very human about it and it can creep out in projects and programs at any moment. Let’s hand the podium over to Daigneau: “If you try to lay it all out there and say, ‘Let’s dream up all the possible services we’ll need,’ that’s the wrong way to do it. There’s always going to be something new you didn’t anticipate, or something you misunderstood because you had too little information. Instead, look at the individual needs of projects and approach it pragmatically from a consumer perspective. Identify and enumerate the services for particular needs; then introduce the services as needed.”
When he says “there’s always going to be something you didn’t anticipate” he touches on something practitioners have learned in the SOA era: There is no final tightly coupled approach that everyone will agree on in all time to come. That SOA adjusted to this fact is a reason it has found as much value as it has as cloud computing, big data and mobile computing have come on line. Read ”Take new approaches to building services with SOA.” For more, stay tuned.
This year, Hewlett-Packard has continued its efforts to stake out a big presence for its tools in the DevOps world – where many organizations see an opportunity to streamline, rationalize and speed up the process of application development and delivery. For instance, the company now offers updated versions of HP Application Lifecycle Management (ALM) and HP Performance Center (PC) along with new Lab Management Automation and Continuous Application Performance Delivery.
Matt Morgan, vice president, Hybrid IT and Cloud Product Marketing, HP Software, says his company has gotten deeply involved in providing DevOps tools because of strong customer demand. He says demand isn’t just among web-focused companies. “A large insurance company that has been a long-term HP customer used to rev applications twice a year but they are now moving to blend development and operations so they can move to a monthly cycle,” he says. Ultimately, he says, consumers are demanding more and better apps and functionality and that, in turn, is driving development cycles across the enterprise. “That is being replicated in every industry,” he says. “Consumers are judging companies by their apps.”
Consequently, Morgan puts DevOps adopters into three categories. At the “top” are Web-oriented companies and mobility companies that started from the ground up with a DevOps kind of approach that supports daily, weekly, or monthly updates. “Search engine companies, Wikipedia, and Zynga are good examples – their whole organization becomes a beta testing site,” he notes.
The second group of companies has not had the same orientation toward DevOps but have “pockets” of new technology adoption where a DevOps approach has been or can be incubated. “A typical example of this kind of company might be an airline where they have hundreds of old apps but they are moving to adopt consumer-facing mobile apps, so in that part of the company they are running those faster cycles,” he notes.
Then, there are all the other companies – the ones that are still operating according to traditional work and development patterns.
“At HP we believe this trend isn’t just about speed and agility; the user is becoming the centerpiece of all design work for software applications,” says Morgan. The implication is that applications can’t and won’t remain “static” any more. There will be a constant demand for upgrades, updates, and adaptations to new business needs. DevOps will be key. -Alan Earls
Web APIs are multiplying as more retailers, media groups, governments and financial services firms start exposing them. At the same time, many companies are still resistant to API management, according to Paolo Malinverno, research vice president at Gartner. The problem with that, he said, is that using APIs is increasingly at the center of what goes on at the “nexus of forces,” Gartner’s term for the convergence of social, mobile, cloud and information. As a result, lack of management could mean serious loss of value.
“It is a fact that the number of APIs grows by the day and, with the explosion of mobile applications, APIs will be used more and more in the future,” Malinverno told a crowd at Gartner’s Application Architecture, Development & Integration Summit this week in Las Vegas.
He noted that daily API calls have skyrocketed into the billions for many well-known companies. Facebook, for example, saw 5 billion API calls per day in October 2009, while Twitter had 13 billion per day in May 2011.
“These companies better know who is calling,” cautioned Malinverno. “They better know how many calls per second they have to field, and they better know what sort of elasticity they need to demand from their cloud platforms to ensure that whoever uses their API is able to use it properly.”
API management is the way to do that, he said. Without it, businesses may lose out on value in their services and their APIs.
“API management is about making an API available on the Web for everybody that you want to use the API—enabling them to call it and get the result they want,” he explained. “Not everybody feels they need API management, but they do. The assessment of the value of the API is a part of API management.”
Malinverno also noted that SOA governance and API management are very closely tied—perhaps even the same. He said SOA governance is “the ability to link a specific intent of your business strategy to the way you develop and operate services.” He advised his audience to build a strong SOA governance strategy together with API management, to create what he called “application services governance.” -Stephanie Mann