Jeff Schneider has a blog post entitled You're so Enterprise... which is meant to be a response to a post I wrote entitled My Website is Bigger Than Your Enterprise. Since he neither linked to my post nor did he mention my full name, it's actually a coincidence I ever found his post. Anyway, he writes

In regard to the comment that Dare had made, "If you are building distributed applications for your business, you really need to ask yourself what is so complex about the problems that you have to solve that makes it require more complex solutions than those that are working on a global scale on the World Wide Web today." I tried to have a conversation with several architects on this subject and we immediately ran into a problem. We were trying to compare and contrast a typical enterprise application with one like Microsoft Live. Not knowing the MS Live architecture we attempted to 'best guess' what it might look like:

  • An advanced presentation layer, probably with an advance portal mechanism
  • Some kind of mechanism to facilitate internationalization
  • A highly scalable 'logic layer'
  • A responsive data store (cached, but probably not transactional)
  • A traditional row of web servers / maybe Akamai thing thrown in
  • Some sort of user authentication / access control mechanism
  • A load balancing mechanism
  • Some kind of federated token mechanism to other MS properties
  • An outward facing API
  • Some information was syndicated via RSS
  • The bulk of the code was done is some OO language like Java or C#
  • Modularity and encapsulation was encouraged; loose coupling when appropriate
  • Some kind of systems management and monitoring
  • Assuming that we are capturing any sensitive information, an on the wire encryption mechanism
  • We guessed that many of the technologies that the team used were dictated to them: Let's just say they didn't use Java and BEA AquaLogic.
  • We also guessed that some of the typical stuff didn't make their requirements list (regulatory & compliance issues, interfacing with CICS, TPF, etc., interfacing with batch systems, interfacing with CORBA or DCE, hot swapping business rules, guaranteed SLA's, ability to monitor state of a business process, etc.)
At the end of the day - we were scratching our heads. We DON'T know the MS Live architecture - but we've got a pretty good guess on what it looks like - and ya know what? According to our mocked up version, it looked like all of our 'Enterprise Crap'.

So, in response to Dare's question of what is so much more complex about 'enterprise' over 'web', our response was "not much, the usual compliance and legacy stuff". However, we now pose a new question to Dare:
What is so much more simple about your architecture than ours?

Actually, a lot of the stuff he talks about with regards to SLAs, monitoring business processes and regulatory issues are all things we face as part of building Windows Live. However it seems Jeff missed my point. The point is that folks building systems in places like Yahoo, Amazon and Windows Live are building systems that have to solve problems that are at the minimum just as complex as those of your average medium sized to large scale business. From his post, Jeff seems to agree with this core assertion. Yet people at these companies are embracing approaches such as RESTful web services and using scripting languages which are both often dissed as not being enterprise by complexity enterprise architects.

Just because a problem seems complex doesn't mean it needs a complex technology to solve it. For example, at its core RSS solves the same problem as WS-Eventing. I can describe all sorts of scenarios where RSS falls down and WS-Eventing does not. However RSS is good enough for a large number of scenarios for a smidgeon of the complexity cost of WS-Eventing. Then there are other examples where you have complex technologies like WS-ReliableMessaging that add complexity to the mix but often don't solve the real problems facing large scale services today. See my post More on Pragmatism and Web Services for my issues with WS-ReliableMessaging.  

My point remains the same. Complex problems do not necessarily translate to requiring complex solutions.

Question everything.


 

Tuesday, April 11, 2006 5:50:07 AM (GMT Daylight Time, UTC+01:00)
>Just because a problem seems complex doesn't mean it needs a complex technology to solve it. For example, at its core RSS solves the same problem as WS-Eventing. I can describe all sorts of scenarios where RSS falls down and WS-Eventing does not.

WS-eventing isn't a good example, thats more something created by architecture astronauts while on the dime of the big sw houses. Enterprises typically are choosing a development platform first. And then they (IT) have various nasty systems shoved down their throat. Sure PHP and its "simple" brethren are fine to build large-scale consumer websites (if you know what you're doing). But bigcos are risk-averse. They want something that has a vendor behind it that can be sued, and that can indemnify them. They want prebuilt APIs for whatever is possible; PHP might not have the libraries that Java or MS platforms have out of the box. Sure people will use RSS or what have you when they can. Hell, enterprises go ALL OUT in many cases with trendy XML integration. But that doesn't change the needs created by a large non-software company that has what adds up to its own software development and maintenance operation inside it. To the extent that some risk can be taken out of that kind of scenarios by having an IBM or Microsoft around as a partner, well management pretty much needs that kind of hand-holding in the real world.

Also, from what I've seen in a lot of cases enterprise developers are _ahead_ of internet companies. Especially software vendors - its amazing seeing overhyped consumer search companies for instance based on technology the enterprise vendors and the customers have already built in many cases like desktop search, faceted browsing, etc.
Tuesday, April 11, 2006 9:34:59 PM (GMT Daylight Time, UTC+01:00)
Dare,

I commented on this post in my blog, which drew a response an Enterprise Architect to the effect that while we obsess about platform and technology choices, most EAs spend their time on software maintenance issues. "The developer productivity benefit of one development platform over another is usually a rounding error in the budget". It's now a guest post on my blog; click the link on my name below to see it.
Comments are closed.