The ITKO Blog: Application Lifecycle Optimization

Showing some ERP mettle for SOA with SAP

So many of our customers have large-scale ERP packages like SAP or Oracle that form the IT foundation of the enterprise.  While at the outset this sounds like a simple architecture, given that you are working with a single vendor over a longer timeframe, in fact these systems are themselves rife with complexity and heterogeneity.  And so many applications now connect into the ERP via various forms of adapters and message buses, that you end up with the classic alphabet soup of technologies at play.

"iTKO/SAP Whitepaper: Validation & Virtualization of SAP Enterprise SOA Applications with iTKO LISA"

This new paper iTKO co-authored with SAP, after working with them in their labs, helps customers see just how valuable a service validation and virtualization offering can be in these environments.  By SAP’s own calculations, customers spend millions of dollars every year standing up and maintaining development and test labs for SAP, even when running on virtual hardware.  And when they need to perform complex integration and load tests with other systems, millions can become $10s of millions to support these environments.  

Our strategy of virtualizing the services layers of these complex applications in a VSE (Virtual Service Environment) like LISA offers is a great way to eliminate those costly constraints, and make it practically zero cost to stand up. This approach is great for our software partners like SAP, and especially for the end customer. After all, we all want to focus IT budgets and especially our integration and innovation efforts toward technologies that contribute revenue to the bottom line, and not manual support and configuration costs that aren't repeatable.

Yes, even big ERP is getting nimble for SOA. We expect even more collaboration with SAP and other software partners to better improve quality and agility for customers with Virtualized Services. You can also find the paper posted by co-author Joerg Nalik Ph.D. on SAP's Developer Network and COIL blog here: https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/14083.

Intermediating ESBs for SOA: The Final Webinar?

OK, sorry to mix metaphors, but it is time to put this can of worms to bed (???). If you've been following this blog you couldn't help but notice the many posts on the apparent ESB vs. SOA controversy. All of this started with an innocent little interview John did for SearchSOA - where the topic of Intermediating multiple ESBs came up. This article created a tornado of posts from some heavy hitters on SOA topics over the last month.

Given all of that, we decided to have our own little webinar on the topic Monday - and we were glad to find dozens of you Chief Architects and senior IT & Dev Managers attending - and asking some great questions about how to rationalize ESBs with their existing technologies, and enable your SOA initiatives going forward.

You can watch an archive of this informal, and informative webinar, with iTKO's John Michelsen, and Chris Kraus here: http://www.itko.com/site/resources/esbwebinar.jsp. Chris demonstrates a little software how-to in the middle of the session for those to like to see the screens.

Hey, are ESBs evil? We don't think so - we've always considered them to be another valuable building block in SOA for many of our customers. The key to success here is making sure you are using ESB platforms, even if they are of different flavors - for doing what they do best in the integration process. An ESB does not make an out-of-the-box SOA. However with good design and architecture principles, and strong validation and Governance, you can mitigate the risks of working with these technologies and bring a lot of your legacy and transactional technologies into the SOA fold with much more ease.

Virtualization of ESB messaging behaviors (and the underlying apps and mainframes they expose) is another way to address these ESB intermediation constraints between teams - say if I'm on the webMethods (SAG) team and need access to the TIBCO team's messaging framework. Or if I'm using Oracle/BEA Aqualogic and need to interact with services exposed through the SAP XI messaging tools. Our counterpart on the other team may want to limit our access to these systems - especially if they are supporting live business requirements. The ability to virtualize away those inter-team dependencies, and have a realistic, stable Virtual ESB earlier in my design/develop/test lifecycles can take away much of the cost and delivery timing constraints inherent in intermediation.

Is this the final time we'll visit this controversy? Maybe not - as long as there is complexity and change in SOA, which is the case for virtually every decent sized enterprise IT shop, there will be a need to rationalize multiple technologies. After all, we have to keep doing business today, despite mergers, compliance changes and new competitive pressures that make us keep bringing in new technologies.

We invite you to sit in on the session and make up your own mind -- and welcome your comments on the content.

SAP Community Network Blogs – First in a Series of Software Community Blogs

As a point of reference, the challenges and solutions we encounter in trying to manage, test and virtualize major vendor solutions have a source in the dialogue of the user, services, and developer communities that support it. Most of these firms have blog communities so we decided to take a survey of them over the next few weeks, starting with SAP.

SAP Community Network Blogs have been in operation for some time. It covers many topics. It is easy to become a member of the SAP Community Network and that gives you more access. You do not have to be an SAP employee to have a blog, only a community member so there are bloggers who work in the SAP space but are not employees. The community site is well organized with blogs by date, by topic, top blog posts, active bloggers, etc. There are clear guidelines on what you can do.

Many topics are listed including: Business Rules Management, Business Solutions, Composition Environment (CE), Emerging Technologies, Enterprise Performance Management, Enterprise SOA, Governance, Risk and Compliance, and SAP Business Workflow. Technorati reports 5,407 blog reactions to the SAP blog community as a whole, so it is well read and have plenty of coverage in the blogosphere.

I took a look at the Enterprise SOA area. One post, Enterprise SOA on SDN and BPX – The Good Stuff Just Got Better  by Mark Yolton of SAP, commented on how they recently reorganized the Enterprise Service Oriented Architecture (enterprise SOA) pages, information, and tools in the Enterprise SOA section of the community. Mark Yolton is Senior Vice President of the SAP Developer Network (SDN) and Business Process Expert (BPX) communities. He said that the Enterprise Services Community (ESC) area has grown and expanded with new members, groups, and successes,” which is good news to us at iTKO. 

Mark goes on to write, “We know that service-oriented architecture (SOA) is about breaking monolithic systems into components to access valuable business logic as standards-based services. Services can be combined into new services that support enterprise-wide business processes and can be reused to maximize efficiency and reduce total cost of ownership. However, effectively managing your IT with SOA principles means your SOA blueprint needs to reflect business semantics. To achieve this, you need a comprehensive governance process and design methodology that safeguards service quality, stability, and standards compliance.”   These are all principles we support.

Another post, How to approach the transformation to enterprise SOA, by Bjoern Treutel of SAP covers their methodology. A post by Daniel Stollenwerk describes the Enterprise SOA Development Handbook. There is a wealth of material here and if you are leveraging SAP in your enterprise (and that's a huge community indeed...) this community is certainly worth exploring.

Feeling Crushed under the SOA Data Requirement?

One of the most  difficult obstacles to attaining enterprise-ready SOA is the sheer scale of the  systems and data that need to be managed. To test the actual results of an application, we need a very realistic set of data – both positive and negative –  to input, and then get out of the environment under test.

True, we can map  much of our interaction with other Services according to the metadata we set  forth during architecture and design processes. But when you get past that ideal  model of connecting the endpoints, you still have the mainframe, or an SAP or Oracle Financials enterprise system, and the  administrative owners of that system, to contend with. The data and business  logic embedded at these layers has been added to and customized over the course  of several years.

So why can't we just  have developers and testers work against the live system?

 

 

Well, those system  administrators might be reluctant to provide access to key business systems in  deployment. Beyond that challenge, getting a bed of realistic test data in place  can be more than difficult – and hardware doesn’t scale to  replicate the terabytes of data such an implementation requires. Implementing a  complete mirror image copy of the system to test requires another enterprise  license and implementation team – far too costly in scope.

In addition, managing data in order to do successful service development, integration and testing can truly be a moving target. It's tough to maintain that context of an actual user moving through the system, without actually having access to every implemented layer.

The best practices  for overcoming the data crunch isn't by any means an easy road, but it has to be  done. It still starts  with good architecture - mapping out realistic business, and the relationships that define them. Next, we need to capture as much  of the data as we need to provide a realistic test environment. There  isn't a way to replicate all of it, but we need to obtain enough to encompass  most of the virtualization of test beds, and the  behaviors of apps as Virtual Services, can help you get to the point of reaching  the 80/20 rule for the data you need most often.

Finally, we need a strong Governance approach to staging, promoting and deploying the application,  which includes continuous testing and validation of the expected behaviors, and  underlying data. No amount of simulation in development can account for all of  the unforeseen consequences of changes in the deployed  system.

Part of our approach is to automate that process of data capture and modeling with Virtual Services. By monitoring a given Service and all of the live and test traffic that is going into, and out of it with LISA, you can get a pretty rich data set. Often people tell me that it must represent only a scenario where the data is not very complex. Not so. Though admittedly, the more complex your data set is, the more elaboration and checking you need to do on that data set. And what if there are data errors within your Virtual Services? Well, in a sense that is what you are looking to uncover, right?

However, it is important to note that there is no shortcut for Continuous Testing & Validation.
When you move into staging and deployment, you need to move from that virtual data model to actually doing continuous integration testing. The point is - to get 80% of the testing you need done at those early stages accomplished by using a Virtual Service data model, then you can have a more dedicated testing effort with less conflict against that live data in deployment.

Obviously, there is  much more to this process than I can cover in a post, but I hope you will seek  out leaders and solution providers that can help you accomplish all three of the  above goals.