|
|
| Service Oriented Enterprise |
|
|
Wednesday, July 28, 2004 Disposable Applications In the early 90's, the company that I worked for had 3 different application platform strategies: 1. Purchase large, off-the-shelf (OTS) packaged apps 2. Build applications that were core to the business (Core) 3. Build rapid apps for non-core or non-long-living applications (Non-Core) Back in those days, we used PowerBuilder for #2 (Core). PowerBuilder gave us enough structured techniques to build fairly complex business applications. It recognized the number one use case in business apps: Capture user information, Save it, Make it available to others. Surprisingly, this DB intensive technique could be used on a high percentage of problems. It stunk at workflow / groupware - but luckily this is when Lotus Notes was emerging. Now we had a tool that could rapidly create collaboration environments for non-structured data. We could also use the people in the company who couldn't code worth a shit (and we couldn't fire) to actually get something done. Yes, we called this people "Notes Programmers". And we had a ton of them. Generally speaking, we considered the Notes team to be creating 'Disposable Applications'. The people were cheap, the licensing was cheap enough, and the throughput was high. We allowed them to knock out small applications - and they did - they churned through them. Then an interesting thing happened... our users started telling us that they wanted the new application to be done in Notes (not PowerBuilder). "What? You want it in Notes??? Those are the idiot programmers that we couldn't fire." I thought to myself. An interesting dynamic had occurred. Our users realized a handful of things: 1. The Notes team delivered applications faster than the PowerBuilder team. 2. The Notes team didn't make the users feel like technical idiots; thus they became friends with the team. 3. On occasion, the users would make small changes to the Notes applications themselves. 4. The users realized that in addition to collecting, storing and retrieving data, virtually all business processes involve workflow and collaboration. In fact, the collaboration was often more important than the structured data. I have the unique opportunity of seeing lots of service oriented offerings. Virtually all of them are of the 'PowerBuilder' classification. Most of them start off by integrating into Eclipse or Visual Studio. Ok - with this as a starting point you have already determined that you aren't a disposable application. The next thing that I see is that vendors expect people to understand XML Schema. This again, precludes the disposable community. Should they know XSLT? Nope. BPEL? Hell no. XQuery? Uh... No. In order to create a Disposable Application environment around a service oriented infrastructure, one thing is absolutely necessary: - The developer / author shouldn't have to know anything about SOA. No Exceptions. Most talented engineers hate environments like Lotus Notes. They roll their eyes thinking about scripting hell, inability to enforce uniform constraints and business logic, inability to leverage a common data model and perhaps most significant, it allows dumb shits to look smart. Talented engineers would much rather create a distributed state machine leveraging a set of 30 WS-Protocols across a messaging infrastructure that leverages a VM that facilitates heap size manipulation, while programming to a set of 17,000 classes that represent the "enterprise API". And oddly, customers are preferring to buy packaged applications that are already fully developed over having custom apps built. Who'd have guessed that one? So, you ask, am I in favor of disposable applications? Hell yes. It may hurt your ego but it will be kind to your wallet. The real trick is to determine how to design a service network to facilitate disposable applications. It should be possible to create a constrained and structured set of services that contain the end development environment enough to allow 'power users' to do their thing. Then, it is off to the races. posted by jeff | 8:29 AM Monday, July 26, 2004 A Note on BEA The recent departure of Adam Bosworth from BEA has many in the industry talking about the overarching issues that seem to be facing that company. As an ex-BEA partner, I witnessed first hand several unfortunate but not so uncommon events take place, including: - trouble with channel conflicts - strong sales people being fired (even in very tough environments) - less than capable people hired into marketing and bizdev - inability to articulate a new vision - failure to create an open source strategy - failure to answer the IBM global services threat - inability to create vertical offerings - chose not to acquire when their stock price was down - despite industry consolidation Now, I get the feeling that there were more issues on the inside - but I can only tell you what I witnessed from the outside looking in. In my opinion, BEA was failing during an absolutely critical period of change in the software industry. - Venture funds over invested and killed the cash cows of medium sized ISV's - This fortified the positions of the large ISV's (MS, IBM, SAP) - Customers were moving to process based applications, not technologies - Large ISV's moved to an agility based packaged app model This set the stage for: -- Microsoft building out .Net and growing Microsoft Business Solutions -- IBM will build out WebSphere and acquire packaged app companies (Siebel, etc.) -- SAP continuing the component/service push on NetWeaver -- Oracle continues to build apps and grow the technology platform (Collaxa acquisition, etc.) All in all, we are seeing a trend; major application companies are going to market with an application platform that they provide. Smaller ISV's are often picking JBoss or .Net. And medium sized businesses are being attacked by aggressive IBM sales teams. So, where does this leave BEA? For starters, BEA should have seen this coming and pushed a deal with either SAP or Oracle some time back. Upon seeing that Open Source offerings was having a significant effect on the low end of the ISV market via rapid commoditization, BEA needed to make a move. Going forward, variations of open source models will dominate markets that are easy to commoditize. Integration will likely be on of those markets - technologist understand the use cases. The departure of Adam Bosworth is only one of many issues for this company. Although their products are sound (from a Java perspective), they moved extremely slowly in their web services strategy. Could BEA acquire enough companies to be considered a 'service oriented infrastructure' company? Maybe - but the market is up and the web service startups are making sales which will substantially increase their valuations. This makes it much tougher to stomach the acquisitions. Let's say they pull it off. Is it a good move? I'm not sure. Mostly, I think it just keeps them around until the next wave of mergers takes place. I wish that I could offer BEA some magical advice. It is a company that has been good for the software community. I don't have the answer, but I have some inclinations: 1. From a technical perspective, look beyond Java. And way beyond J2EE. 2. QuickSilver and the ESB space are already commoditized. Back an open source project. 3. Web Services are easy, "Integrated Service Networks" are hard. 4. Understand why people like the idea of a "Google computing platform" 5. Packaged apps will dominate until the build vs. buy dynamics reverse. Unless you plan on being acquired soon, your job is to reverse it. It's that simple. As I look at these 5 items, I realize that this is good advice for any of the ISV's that plays in the app-dev, or integration space. Here are a couple more things to chew on: - web services and service networks increase the complexity of the enterprise I.T. stack - the more moving parts there are the more it costs to bring them together - not all buyers need the same level of complexity (if only we had J2EE Beginners version, J2EE advanced version, etc.) - service oriented infrastructure will be most beneficial to very large I.T. shops - if you refactor software out of the application and into the network, you should be able to reduce the development and integration time - if you didn't; you failed. - Remember - dBase, PowerBuilder and ColdFusion. Developers like when you make them look like rock stars - give them the tools to beat expectations. I feel a bit sorry for them, but mostly I'm mad. As the turnover continues at BEA we can be hopeful that they'll either acquire the companies with the talent or bring in some new vision to steer the ship. Despite my frustrations with them, I wish them the best of luck. posted by jeff | 8:59 AM |
|
|
|
|
||||||||||||
|
 |
|||||||||||||||
|
||||||||||||||||
