Open Source Business Applications

In a recent article on CNET news, I found SAP’s commentary on Open Source Business Applications pretty interesting. Does SAP have a reason to fear the Compiere’s and SugerCRM’s of this world? I think so.

The more I delve into the subject of Open Source Business Applications, I find that there are quite a large group of people who tend to agree that ERP and CRM could be the next OSS killer apps.

The most important part of any SAP implementation, is business process re-engineering, a standard procedure that any business should have to go through when implementing a system that automates a large number of their processes. This is the most critical part of any ERP or CRM implementation. You cannot implement SAP or any other ERP without understanding the processes in your business, and at the same time, how to implement them in the Business Application of your choice.

And it’s here where I believe OSS has an advantage over proprietary solutions such as SAP, Oracle and the rest: Due to the proprietary nature of SAP (and the rest), business are forced to use expensive consulting to implement their processes, and quite often, processes need to be “standardized” or changed to work well with the application.

Applications are easier and easier to build these days. Most of the larger ERP systems are J2EE based systems, because of the flexibility that this architecture allows. SAP and Oracle have made a large investment in Java, and will continue to do so, because it is simply the most effective way of building SOA applications today. There are hundreds of open sourced java frameworks to choose from, and SOA or SODA development style allows developers to build systems that can slot into any larger enterprise architecture. From a technology perspective, the top OSS ERP systems do not have to stand back an inch for the more expensive SAP, Oracle and other suites.

SME’s will benefit most

Driven by the implementation of SOA, the new OSS business applications have the ability to integrate seamlessly with the rest of the applications in the business. The organization at least has a choice about how certain processes can be implemented, and who implements them. An open source ERP like Compiere, for example, is freely downloadable, and includes all of the functionality that an SME requires. And this is where I believe the most adoption will be: SME’s, and some bigger organizations who have stronger OSS strategies.

Summary

To successfully implement any application that automates business processes, the organization must understand these processes well enough to automate them. Not from an IT level, but from a business perspective. IT is a tool to automate business, and shouldn’t be treated as the process whereby business is modeled. An application should never have to change the way you do business, but needs to be able to be adapted to business requirements, which are ever changing.

Which brings me to my point: Why spend millions on technologies, such as SAP, if the true value behind these systems are your own processes? And these processes could be as easily implemented in an Open Source technology, at a fraction of the capital and implementation cost? In my mind, the answer is simple. Open Source Business Applications, such as ERP and CRM, are here to stay.

Linux - Enterprise Ready?

Ok, so this topic has probably been debated to death. I've got a different perspective of this issue , and I reckon it's worth putting down in words.

Over the last few weeks, I've been involved with one of our local customers, who after a lot of consideration, has decided to make the linux jump. This was no quick decision, mind you, and was more than a "I'm tired of paying microsoft for licenses" thing.

Why the move?
Linux made it's way into the organization by me choosing to use it as a desktop system when I was still consulting to the customer, as a DBA and J2EE developer. (Yeah, I know, a weird combo, but I've never liked scripting languages much, so chose Java/J2EE for my DBA tools). I got pretty uptight when Eclipse and Windows (the company standard) decided to crash or hang on me every few hours, and I swapped back to Linux.

As a DBA, you tend to get involved with all sorts of issues, mainly because in the case of a reasonably large or busy application, the database is normally the first thing that takes the blame in the case of a performance dip. On one of my investigations, I found that the database had trouble sending data back to the client applications (network waits). The networking guys were just laughing at me, and told me that the database shouldn't send so much data back. (!?!)
There were some variables involved: All of the servers (application servers, web servers, database servers, mail servers) where hosted at a different site, and all traffic (including web traffic) where being routed to (through) the offsite location (a local ISP). My theory was that some people were misusing the web, as my investigation pointed out that HTTP traffic was extremely high.


This was really the first case where I could implement Linux with a direct business benefit. After a lot of consultation with the client (a Windows only type), I decided to take an older PC standing around in the storeroom, slapped some SCSI drives into it, and installed Mandrake Linux on it. My reasoning here was that Mandrake is a pretty friendly O/S for a Windows skilled "LANnie" to pick up. I then went for Squid proxy, and installed a web reporting tool (squint) onto the "proxy server" as it was called. This allowed us to report, per user, the amount of time spent on web sites, the amount of data downloaded, site details etc etc etc. We could basically pinpoint exactly who was surfing, for how long, and what sites they were viewing. We had to change some of the and client browser settings to point to the proxy (you change firewall rules to only allow http traffic from the proxy server, and the point all client browsers to the proxy)

We gathered statistics for 2 or 3 days, and our first report proved that my hunch was correct. Some guy in the admin department was using up a lot of our much needed bandwidth by downloading, well, porn. And some other guys where using the web for audio streaming. And some other guys where downloading MP3's and games etc etc. Now, in South Africa, bandwidth is expensive and slow. We only have one provider of leased or other telco lines (changing in 2006), and 3G isn't what it should be (yet)

We blocked some sites, the client issues some final warnings, and by the next day, the system was flying again. I started using our "proxy server" for more things, to see how much we could get out of a simple PC (about 128 mb ram, 40gb disk space, 1 ghz pentium 3 cpu). We implemented CVS, an open source version control tool. We gave users in the Operations department a home directory to backup documents. We set up some print queues.

The CIO was pretty happy with what we managed to squeeze out of the PC. The key thing to realize here is that Linux could significantly benefit the business by doing small things very well, at a low cost. The question was, could it take over critical operation in the enterprise system?

To me, the best place for Linux today, is with the most "invisible" part of the business: the data. A database should do one thing very well: Store data, and provide easy and efficient access to it. It doesn't need fancy GUI's. It doesn't need wizards, graphs, reporting and other things associated with client applications. The database is a storage engine (with a few twists). Linux on the desktop hasn't been successful so far, because of many reasons, that I'll address in my next post. But for database servers, application servers, web servers, mail servers? If configured correctly (on any operating system) they tend to run in lights-off mode for most of the time, or they should.

One of the issues in the environment, was that you had to reboot the Windows servers pretty regular, especially the database server. The database engine uses a lot of resources, and was pushing the box to the limit. I felt that a Linux O/S would be a better database server than Windows could, as for one, you have more flexibility in tuning Linux, and I perceive the Linux O/S to be more stable than Windows, after years of working with both environments. Especially for a RDBMS.

While we where contemplating the shift, the Windows O/S did it's best to help our decision. One night, I got a call at 3 o'clock in the morning, from the network admin, and was told that they couldn't boot any of their servers. A virus managed to corrupt the ntoskernel.dll file (or something like that), and the O/S had to be recovered. (At least backups were complete...) Something went wrong on the recovery, and by the time I arrived on site, was told that the O/S had to be trashed, and we would have to revert to backup. We lost about 4 days, due to wait time for hardware, O/S configuration. After that, the writing was on the wall - we were going Linux, wherever we could. As a matter of fact, we already had 2 Linux servers in the rack: Our integration server, and a server that was responsible for client communications (generated PDF documents and mailed it out)

Even before this happened I presented a greater Linux strategy to the customer. Here is a high level:

1. First, we move the database servers to Linux.
This is the lowest risk, because the users aren't affected at all - except maybe that we expected more uptime and better scalability. In effect. We didn't anticipate too much of a performance boost - moving to Linux on the same 32 bit hardware wouldn't make too much of an outright performance change, but we were expecting a small improvement.

2. Move the web server (IIS) to Apache or Tomcat.
Most web servers in the world run apache, and it gets rid of having to pay licenses for a commodity. Another thing to mention, is that the customer's enterprise application runs a J2EE webapp, and it was felt that we should standardize the corporate website to something like JSP, which could be supported by more than one person, and can run on multiple environments.

3. Move the application server to Linux.
This should've been easy, but it isn't. The early application developers used the Powerbuilder Datawindow in their J2EE app, and we weren't convinced that the move would be seamless. So we left this until last

4. Convert all remaining client-server apps to thin client, browser based apps.
A browser based app would mean that the end users could use any o/s and browser they felt comfortable with. Also, it puts the business in a position to test out Desktop Linux, and do this at their own pace. Why would they want to? The most significant saving to be made out of a corporate Linux shift, is at desktop level for application users. Power users may still want to run Windows, but for the guy who comes in the morning, switches on his PC and fires up his email client, and the application he requires to do his work, he could use ANY operating system. Mac, Linux, Windows, Solaris.

Even better, you probably don't need the "enterprise" version of Linux at desktop level, meaning that the O/S won't cost you a cent. Now, calculate this for an organization with 500 users? And remember to add up Office and any other Windows licenses, etc etc etc.


5. Desktop Linux, where it makes sense.
More of the above. There are some good articles out on the web from various authors that point out that most Windows fans, are really Office fans. Microsoft Outlook is the de-facto standard for organizations, because of the integrated collaboration. But, the largest portion of employees in a standard sized organization, probably uses about 15% of Office. It makes sense for these users to try out OpenOffice. Tactic here was to install OpenOffice on Windows, swap the mail client to something like Thunderbird, and do proper UAT to see how that goes.

6. Mail servers.
Depending on the business, and how the organization uses the Outlook Calendaring (if they use outlook at all), this could be an easy or difficult shift. In this case, about 30% of the users in the organization uses Outlook with calendaring. So, not practical yet. So how do we do this? In this case, it doesn't really matter. Windows and Linux can co-exist pretty easily in the environment, and I would never advocate a "rip and replace" strategy. The best strategy we can think of now is to go for a CRM (the client needs, and wants to implement CRM) that integrates collaboration. First choices for now: SugarCRM, and possibly Compiere.

So the customer was ready for phases one, two and three. When we started strategizing the Linux shift, an interesting question came up, and it's one that comes up quite a lot now: While we're doing this move, how about investigating 64 bit architecture? Surely this will also make a massive difference? Our initial test showed that we would get a 10% - 15% performance increase by using our same hardware, but that's fairly insignificant. Sooner or later, we would run into hardware limitations. The Linux shift would extend the use of the current hardware to about 8 months, and this seemed to be a short sighted strategy.

The customer asked what was needed for a "significant" performance improvement at the database level, and how can we ensure that our hardware lasts us for the next 5 years? The key thing about a database, is that is only as fast as the amount of I/O requests it can process. And generally, disk writes and reads are very expensive, slow I/O operations. To offset this, you throw RAM at the problem, and increase the database cache so that it doesn't have to do as many direct disk reads and writes. There's a lot more to this, but that's the basic rule. This is especially true if you are sure that the database engine has been properly configured to use the machine resources efficiently, and that all of the queries thrown at the server are optimized.

The limitation for this particular client, is that they were running 32 bit Linux, which has the limit of only being able to address 4 gb of RAM per process. This means that your database server can only address about 3GB of RAM, seeing that the upper limit of that memory is used by the O/S. And moving to Linux won't solve that. There are some clever things you can do with memory (especially on Linux), but these are mainly workarounds.

A 64 bit processing architecture would solve this. There is no practical limit of addressable memory per process, and any application that relies heavily on data processing could benefit from a more processing cycles.

There are other ways to ensure that your production system stays manageable. Archiving is probably the best strategy: You can keep your production system flying by ensuring that you only store "current" data in the production environment, and archive the data to a secondary, larger and slower system. With current regulations, data needs to be kept online for longer periods, and doing a tape or disk backup and putting it in a safe is not good enough. I'll do another post on archiving at a later stage. This client decided that they would throw hardware at the problem. This can (and probably will eventually) backfire: A faster, bigger system allows you to collect and store more data in a shorter space of time. Already, statistics say that data is doubling every 2 years.

Back to the migration. After lots of investigation, testing, and sitting in labs with hardware vendors, providers and partners, we decided to go for the IBM OpenPower 720E, RHEL 4, and an IBM blade solution (all intel servers). The client decided to move the complete architecture to one Vendor (IBM), so the SAN, domain controllers, and everything was moved to IBM hardware, to get answers from as little vendors as possible in the case of a failure.

The OpenPower would run all 3 production database servers (Sybase ASE). This meant we were consolidating 3 separate machines (all 3.2 GHZ 4 way HP Proliant, 6gb ram each) into one machine. 4 CPU's, 24 GB of RAM. (I pushed for 32, the maximum the box could take, but no luck).

I'm not going to go into too much of the installation and configuration detail, but it was fairly painless. There were some issues that were fixed pretty easily, and after some extra Linux tuning, here some of the most important statistics:

The customer runs a "payment-run" every week, per country. The payment-run for the largest country took more than 6 hours on the older system. New System: 45 Minutes.

Another daily process to summarize account details normally took 17 minutes. New System: 3 minutes.

An application that does B2B style transaction processing took 8 seconds per transaction previously. Currently: 1 transaction per second.

CPU usage is down from 80% to 35% on average. And remember, 3 database servers were consolidated into 1.

To summarize, we've got about 90% of the servers running RHEL 4 now. Overall system performance improvement is dramatically better. Now for the desktops.....

Day 5 - Vienna Bootcamp

On the last day of the Bootcamp, we covered EAServer 6, and Avaki.

An interesting piece of news was that Sybase have plans to turn EAServer into the fastest, high-performance application server around. To achieve this, EAServer has been completely re-designed into a much more lightweight, high impact architecture. This goal of Sybase is pretty ambitious, but makes a lot of sense. Tools like UO run inside EAServer, and if the throughput is not high enough, an integration bus like UO will never succeed, and therefore the promising Workspace could also fail.


To make things nice and short: The new architecture looks a lot better than it currently is, every object is a java object, and the support for other app servers is a lot better. You would be able to add EAServer as a plugin to other web servers, some of the proprietary code has been replaced with the current standards in the J2EE world and a few patents have been registered with regards to design. Still early days, but Gartner has commented that EAServer is a promising product, and I have to agree that these new changes seems pretty good.

Avaki: Wow. What a product. I don't know if Sybase fully understands what they've got here - this product is unique and could change the way we think about EII. Data integration is a hot topic, with ETL and EAI, and (slot your 3 or 4 letter abbreviation in here). Avaki is a grid technology data abstraction layer, that allows you to incorporate and integrate different sets of data, structured or not, into a virtual database or virtual storage location. This could very well be the answer to single view projects, and will challenge the way we currently integrate data.

You can expose tables, data operations, unstructured files etc as data services, which could be consumed by JMS or other Web services. I still need to spend some more time with this product, but again, a few people I know would sit up straight when I show this to them.

Anyway, flying out tomorrow. I'm very nervous about my flight back from JHB, from Schipol Airport, as I only have 45 minutes to get off the plane from Vienna to the other one. Great....

Day 4 - Vienna Bootcamp

For day 4, we covered the SODA part of Sybase Workspace. Without going into too much detail, the day was about orchestration, service creation and consuming the services in a variety of ways. The product is very impressive, but will take some time to understand the "why" part of the equation. What I mean with this, is that while the product is technically very sound, we need to find ways of expressing how our customers could use these features pretty quickly.

Another cool feature was the work done with the wtp project. Sybase have built a tool in Eclipse specifically for web development, and have integrated this with JSF. JSF (so far) is not our chosen architecture, but still looks useful. Combined with Hibernate, this framework is pretty flexible, and I liked the visual way of developing the applications.

Samir Nigam also demonstrated the datawindow capablilities from Eclipse. We created a JSF application, with datawindows as presentation layer, and called a web service to calculate a stock quote. This is what Workspace is especially good at: combining different technologies under one framework, and making deployment very easy. By the way, you don't need EAServer to run these datawindows, we deployed to Tomcat!

Tonight, we went out to Strassendorf to the "real" Vienna as our hosts put it, to a little restaurant. Food was very good, but in the end, the restaurant ran out of beer... Now, this might sound interesting, but I counted the bottles on our table, and there weren't even ten. Earlier in the week, we visited an Spanish(?) restaurant, and I waited for 2 hours before my food arrived.

I still can't believe how cold it is here. Apparently it gets a lot colder, but coming out of 30 degree celcius into this -4 degree cold, is a bit strange.

So far, the bootcamp has been very good. I've met a few guys worth remembering, and the highlight so far was seeing what Vladimir did with his best practices stuff. As I mentioned, Workspace is pretty cool, I'll need some time to formulate some ideas about this product. Positioning is key, and the product has so many facets, that you could easily get this completely wrong.

Tomorrow is the last day, and we will be covering Avaki. I'm pretty interested to see what this is about, data virtualization is an interesting concept which I feel could be used more in a lot of projects that we are busy with.

Day 3 - Vienna Bootcamp

Finally, the end of day 3. It's about 2 in the morning, and I'm still working away. I had to work on a customer proposal after a full day's training, discussion and getting my head around a bunch of products. Needless to say, I've decided that I've decided to call it a night now, and decided to wrap up my thoughts of the day.

Ian Thain presented all of the PowerBuilder type tools this morning, covering Powerbuilder, PocketBuilder and Datawindow.Net. I got my hands on a copy of PB 11, which is not Beta yet. This version contains the much awaited .Net CLR compiler, which will allow PB to run as managed code under .Net 2. Apparently, Powerbuilder sales were up 15% this quarter, and some questions were asked as to why, but no clear answer came out.

PocketBuilder and DataWindow.Net could have something to do with this, but one would have to go to that 15% and find out why they decided to purchase. Sybase is showing some good commitment to this product line, and with PB 12 already being worked on, this tools is sure not to go away, and I'm looking forward to it's re-invention as a smart client tool, as opposed to client-server.

By the way, have a look at this site if you're one of the guys who believe Powerbuilder is dead. The PowerBuilder DataWindow is still the best data display and modification component around. Full stop. Nothing beats this technology, it's been around for ages, and is getting better by the release.


Ian did his Pocketbuilder futures presentation that he presents so well, and did at the ISUG roadshow in Africa. This is one of the most interesting tools in the set, purely because everything that is brilliant about Powerbuilder is in it, and a lot more. Wish we could do more with marketing this product, but I guess that's my job now, for SA and Africa anyway....

Then, we started with the Workspace program for the day. Xiau started with how to use PowerDesigner in Workspace as an MDA and MDD tool for creating services applications. This was brilliant, and proves why PD is rated so highly. For the developers who understands what web services is at a high level, but aren't exactly sure how to get it done, have a look at this tool. It abstracts the difficulty from the Analyst/Architect/Developer, and is able to model and generate all of the code needed to implement SOA. Really awesome stuff.

Something that I forgot to mention yesterday, was the PD enchancements to the information liquidity model. You can now model replication into IQ with Powerdesigner building staging tables for an ASE database should you need to use RepServer to get data into IQ. Drop me a mail or a comment should you want more info, this really works great, and lots of our customers will want to see this.

Then, we went through a lab session on Workspace. First we covered the database tooling. One of the initial comments, is the fact that the database painter (from Powerbuilder) will probably not stay in workspace for too long. The engineering team needed to have something, and the PB stuff was there, but the idea is to have a pure java plugin for this, keeping the options open for running this on Linux (maybe). Obviously, PowerDesigner only runs on Windows, so if you want modeling inside of Workspace, I guess you'll have to stay on Windows for your desktop. Servers could be anything, though, so it keeps to the trend where people are migrating server platforms, but keeping the rich functionality of Windows on the desktop. I'm a big Linux fan, but I guess you need critical mass for a port like this (PD on Linux).

Anyway, back to database tooling: Very slick indeed. It's one of the best stored procedure development tools I've seen for a while. DBArtisan is very good, but this (from a stored proc and trigger development perspective, not administration) seriously kicks but. Code complete, debugging, syntax help, all built in. Unfortunately, only Sybase support for now, but Sybase is helping Eclipse to build the DTP (database tooling project), which will allow other vendors to extend on this functionality. Wouldn't help Sybase if they did development for all the other vendors now, wouldn't it?

The lab we did today, took us through the process of developing a stored proc, creating a service for it, deploying it into UO, and testing it. Very easy, pretty simple and very effective. Most databases can do Web Services in the database, but you still need to orchestrate them somehow. I kinda like this idea about deploying the service to a services container, and not keep it in the database. Somehow, I've always believed that data is the database's problem, not all sorts of other things.

All in all, a good (but long) day. We had some mixed feedback at the end of the day, where some guys felt very positive about Workspace, some thought it was too complex, and other just didn't get it. Combining PD modeling with services is very aggressive and ambitious, but Sybase needs to be aggressive with this, I feel. There's definitely room for something like this, and if you buy into the whole MDA and MDD thing, we could be onto something brilliant here. What I keep on repeating, is that this tool is only on version 1.0. The integration with the Sybase servers works well, no blue screens (yet), and the documentation is brilliant. The only criticism I have, is that you need to be very careful when installing this, and make sure you've got enough disk space and resources. It's pretty fat, but it'll get better.

Gonna get to bed now, tomorrow's gonna be tough.....

Day 2 - Vienna Bootcamp

Day 2 started with breakfast - can't really say it was the best breakfast that I've had, but hit the spot anyway. Didn't really have dinner last night, was a bit tired after the flight.

I've just arrived back at the hotel after a pretty full day. We had dinner in a Spanish (?!!) restaurant tonight, and the food was pretty good. Was looking forward to some real Austrian type restaurant, but someone mentioned that there is some tie between Austria and the Spanish.

Anyway, today we covered Vladimir Maruna's section on a methodology he calls BestPractice, Xiau Wang covered the new Powerdesigner Features, and Hugo Pedro from Sybase Portugal covered some interesting applications of the Powerdesigner tool.

Vladimer's session was probably the best of the day. Back in South Africa, our training division picked up on a need for a industry standard business analysis course, and packaged it for the developer and business analysis. BestPractice gives Powerdesigner fans what they've needed for a while now: A simple methodology to model complex business requirements, specifications, processes and domains. I've had the displeasure to try and implement RUP before, and this really seems tons easier.

Xiau was up next, and launced into a presentation and demo of the new Powerdesigner features. There are so many useful new features, and I would have to study these presentations in greater detail to remember all of them. The most significant ones were Hibernate and JSF capabilities from within PowerDesigner (and subsequently Workspace). I will ask him what the plan is for Struts, and other architectural design patterns. The JSF demo was pretty impressive, and it definitly seems usable and very practical, so I'll reserve judgement for now. The Hibernate stuff is very cool, I'd like to see them add Torque to the mix.

Another excellent feature, was the mapping editor. With this, you could do O/R mapping XML/R mapping etc etc etc in a more useful way than currently possible. There are plans to extend this functionality to do more complex ETL type modeling, but for now, only simplistic ETL design is available. By the end of next year, I believe PD should be ready to integrate with ETL tools pretty well.

To me, these were the most important things to mention. There are some enhancements to reverse engineering, forward engineering, reporting, and they're all pretty good, and I think that existing users will be pretty happy with version 12.

Hugo Pedro's presentation had a bit of a different spin to it. Recently, I've been surprised with the amount of internal metadata projects are on the go in the South African market. Most big companies have the requirement of having a business view of the enterprise, and are spending huge amounts of cash to get to some form of a solution. According to one of our larger customers, no vendor has a full solution for this problem. My feeling is that something like Avaki fits perfectly here, but let's put that aside for now.

Hugo and his team have developed a web based solution that sits on top of the Powerdesigner repository. For now, it's read access only, but it will not take any rocket science to figure out how to apply metadata to this, or in fact change the model by changing the repository. I can definitly think of at least 4 large companies who will want this app as is, and one who will use it as part of their metadata project.

Then, Hugo demostrated how one can modify the Business Process Modeling side of PD to extend SOX (Sarbanes-Oxley) into the BPM side. It's a pretty good solution, but might need a bit more than this. I have the demo and models available, so if anyone wants to see them, drop me a comment.

All in all, a good day, but too much death by Powerpoint. Hopefully, day 2 will be more interactive. Still, got some pretty good direction, and met some people worth knowing... Ian Thain is up tomorrow, and will cover the Powerbuilder type products, like DW.Net, Easerver, Pocketbuilder and Powerbuilder.

Vienna - Sybase Development Tools Boot Camp

I'm in Vienna this week, my first trip to Europe. Haven't seen much yet, except the duty free sections of Airports, after my 10 hour flight from Johannesburg, and a nice 3 hour stopover at Schipol Airport in Amsterdam. Then, the 2 hour trip to Vienna, and a half an hour taxi ride to the hotel here in Vienna.

When I arrived here at the Trend Albatros, it just started to snow. Now, to all you Europeans, that possibly doesn't mean much, but the last time I saw snow, was in 1982. (It doesn't snow much in South Africa). And back then, I was 4 years old, and I can't really say that I really understood what the fuss was about. (But Dad, I see snow every day on TV....)

I work for Sybase South Africa, in Johannesburg. I used to run Professional Services for our division, but decided that I would like to take on the responsibility of managing the Sybase development toolset from a pre-sales perspective.

This boot-camp probably came at a very good time. I have extensive practical experience of most of the products that I manage, and understand most of them pretty well, but Sybase has been busy and there are some exiting new things which need some attention. I don't only manage the development tools, I also (for now, anyway) have the same responsibility for the data services tools.

That's possibly enough of an introduction. I'm gonna use this blog to diarize whatever happens this week, and then possibly try and use it to see if we can get some other interesting opinion pieces about the state of software development, integration and information management.