10 Developer Tips for Getting the CEO On Board
As web services have matured, many developers are getting eager to tap into their traditional "glass house" legacy systems. To take that step, however, Java and C# developers will need approvals from top line managers. An exec from Attachmate, provider of legacy emulation and integration, provides IDN with 10 good tips for winning them over.
Director of Connector Services
As web services technologies and core standards have matured over the past year, a growing number of developers and vendors are eagerly looking to tie in web services in with traditional "glass house" legacy systems. This ability to access and leverage business rules (including process, business intelligence, workflow, exception handling/rollover) could all be part of the next wave to interest in web services (circa 2003).
But, to get there, developers need to have better ways to get their Line of Business managers -- and maybe even their CEOs -- on board. So, what are the rules of engagement for traditional departmental developers?
Attachmate, a long-time provider of legacy emulation and integration tools and services, says that that top managers at their customer companies want to improve connections between legacy and downstream assets. And, Attachmate hastens to add, that means both machine assets (software, business logic) and people assets (developers, sysadmins, GUI specialists).
Toward that end, Attachmate's Director of Connector Services Ron Nunan
has provided IDN a Top 10 list of suggestions to help web service developers.
10 Developer Tips for Working with Lines of Business
(and the CEOs They Report To)
- Open standards are good, but don't be limited by them: An application should always work well for its intended purpose and must always achieve its goal for its line of business. But keep in mind that requirements change and evolve, so always add the need to be extensible as a requirement, and build in hooks up-front.
- Market your applications internally: If you can meet multiple departmental needs with one application, you'll be the MVP of the year. But you have to get the word out to demonstrate how easy it is to reuse the application solution in total -- or part. Again, it is imperative to make the application as an abstract set of components/or functions because monolithic or pure point-to-point solutions tend to have little reusability.
- Proactively extend the "glass house" for use by the rest of the organization. Be aware of the "glass house" mainframe environment with its inherent security that deliberately limits access. With the proper tools, glass house applications can be accessed as if they were originally built to be extensible, even though most were not. Go ahead and leverage those applications that already exist, but look for developer tools that allow you to safely consume the portions of the legacy application you need so you can efficiently tap the legacy systems without raising well-founded security objections.
- Keep your communication logic flexible: Instead of building the application's communication logic directly into the application, use an abstraction layer. This allows you to embrace the changing client requirements -- COM to .NET to Java to EJBs, etc. Building in this flexibility allows for future changes to architectures, without the requirement to rebuild solutions from scratch.
- Technology is not for technology's sake: No need to say more.
- Keep it simple by not exceeding the requirements of the request: Use standards to come up with a solution that is versatile, but not enormous. LOBs do not want to pay for another department's project, but they will want the flexibility standard interfaces provide.
- Proactively ask LOBs how you can help: Don't be afraid to ask for assistance upstream. If you're not just on a "fishing expedition" with new technology -- and you know you have a great idea for simplifying their department processes, lives or, better yet, make more money, you will be a hero.
- Be on the lookout for duplicate efforts: Don't program in a vacuum, and get out of your "silo." Stay tuned in to what's going on in IT, so you are aware of another department that may be developing a similar application. With the right tools, you can leverage these efforts without having to re-create or even replicate them.
- Look for opportunities to give more control to LOBs: Some great tools out there can allow LOBs to tweak applications for a specific scenario, without being versed in Java (or Cobol -- or any other code, for that matter). A definite win-win.
- Keep central management in mind: This doesn't mean investing in a large-scale management system. Instead, make sure each solution built is manageable from a single logical point. Older solutions are constantly being tapped into to service newer requirements. This raises management challenges, as modern solutions often span systems, platforms and technologies.