Core to the effective operation of any government IT department is its ability to reliably and securely service existing operations, while rapidly and cost effectively adding new capabilities and responding to changing requirements. However, the proliferation of diverse IT systems within government agencies has resulted in disconnected islands of data across federal, state and local IT systems -- meaning government executives are forced to work with many different existing applications and legacy platforms to service their agencies' changing missions. If there was one industry that could stand to gain the most from a Service Oriented Architecture (SOA), but also has the most roadblocks in the way of siloed systems and existing IT applications, it would be the government.

The COBOL programming language has been around since 1960 and has found its way into virtually every type of business application, and government IT systems are no exception. While existing IT applications represent a major government asset in terms of the unique business processes they contain and deliver, changing business requirements (such as the demand for cross-agency data exchange, cost management control and the necessity for enhanced citizen services) make IT modernization a necessity. However, the endless amount of irreplaceable, mission critical data contained within the government's aging IT infrastructure, paired with the lack of success of traditional "rip and replace" methods, raises flags when the word modernization is throw into the mix.

As agencies move to transform IT systems to meet changing market demands, a low-risk strategy to bring aging applications into modern environments must be determined. The three most common methodologies available for government agencies to update existing IT systems are: rewrite, package or modernize.

Rewrite, Package or Modernize?

A complete rewrite, where an entirely new IT system is built in the contemporary language of choice would seem like the most viable option as it directly addresses emerging business requirements. In reality, the "rip and replace" strategy is often plagued by high costs, a slow time to market and problems with integration. Additionally, the endless amount of critical data held within existing IT systems and applications, along with the fact that with this type of project failure is not unusual, make a major systems rewrite a high-risk strategy.

-1-

Explore Our Topics

• BPM & Enterprise Architecture
• BPM Standards
• BPM Implementation
• BPM Best Practices
• Cloud BPM
• Continuous Process Improvement
• BPM Governance
• Service Governance

• Business to Business (B2B)
• BPM for Supply Chain
• BPM for Customer Management
• BPM for Financial Services
• BPM for Healthcare & Insurance
• BPM for Government

• Business Activity Monitoring
• Event Processing
• Process Intelligence
• Business Rules Management
• Decision Management
• Operational Intelligence

• Workflow Automation
• BPM & Enterprise 2.0
• BPM & Web 2.0
• BPM & ECM
• Case Management
• Collaboration
• Enterprise Portals
• Social BPM

• BPM & Cloud Integration
• BPM Analysis & Optimization
• Business Process Simulation
• Process Visibility & Monitoring
• Process Orchestration
• Process Discovery
• Process Modeling

Home
Webinars
Blogs
ebizQ Forum
All Topics
Subscriptions
White Papers
Analyst Corner
Follow us on Twitter
Fan us on Facebook

Explore Our Topics

BPM Strategy
BPM Solutions
Event Processing Strategy
Content-Centric & Collaborative BPM
Process-Centric BPM

About Us
Editorial Submissions
Feedback
FAQ
Advertise With Us
Site Map
Privacy Policy
Unsubscribe