I agree with Dave that business systems have a lot of the characteristics of ULS systems. In fact, the ones I know are a collection of different LS systems. These LS systems were built over three or four decades, and run on a variety of platforms. Many belonged to companies that were purchased, and then their software was tied into the main corporate system. Corporate philosophy changed over time, and sometime the software still reflects old ways of thinking. So, these systems already serve diverse stakeholders with competing objectives. It is theoretically possible to replace them, but it is too expensive to do so. They are inextricably connected to the day-to-day mission and continue to evolve over time. People are sometimes surprised by the behavior of these systems, so sometimes the behavior is emergent. There are no complete specifications. It is possible to specify the components, but most companies don't do a very good job of this. it is not possible to specify the entire system, because it changes every day.
I disagree with Dave in one thing. Most corporations don't try very seriously to "engineer" their software. For one thing, they don't try very hard to specify it. There are exceptions, of course.
Another place where large software is developed without a lot of plans is in the open source community. Andreas Rabb talks about Squeak development at
http:/lists.squeakfoundation.orgpipermailsqueak-dev2006-October/110246.htmlKrishnasPositionStatement focuses on model driven development. I am a big fan of developing models of parts of the system and generating code from them, or interpreting them. However, I don't think that it will make much difference in ULS systems. There will never be a single model. One way to make a component more adaptable is to develop a model of the component and to generate code from that model. But different components will need different modeling languages, and it will not always be possible to develop a model for a component.
Eric Evans' book Domain Driven Design talks about how a large domain model must be divided into "bounded contextx". Within a bounded context, everything must be consistent. However, things are not consistent between bounded contexts. Bounded contexts change, and it is important for the group working on a bounded context to be small enough to react quickly to the changes. There are many possible relationships between bounded contexts. Sometimes their is a layer between them because one of them is changing without notifying the other. Other times one group acts as the customer of the other and makes sure that all changes are something that their customers want and are ready for. Some contexts are core, and are developed slowly and by concensus of the customers. There will not be one model in a ULS, there will be many. For the entire internet, ther might be millions.
CORBA is not suitable for ULS systems because it is too rigid. (It will be used anyway, of course.) Interconnection schemes based on RPC are hard to change. It is better to have interconnection schemes based on something like XML, since it is easy to add new fields to a document and components that don't understand the fields can ignore them. EJB is also based on strong interface checking and so will not be a good ULS interconnection mechanism. SOAP is better. COM interface lookup was a nice idea for building ULS systems, but the implementation was flawed because it forced reference counting and assumed shared memory. RESTful web services and asynchronous messaging services are probably closer to the ideal internconnection mechanism for ULS systems.
One of the characteristics of a ULS system will be that it will use a wide range of interconnection mechanisms, and it will change over time. We can define the WWW as everything using HTTP that is publically available, but often web servers are connected to RDBMSs using TCP/IP but not HTTP. Some applications talk to each other by sharing the RDBMS. The WWW uses telnet and ftp as well as HTTP.
I think that one of the biggest challenges in a ULS system is coping with change.
Components will change their interface. New components will appear, and old ones will disappear. We need better ways of dealing with this. Flexible interfaces are important, and checking must be at run-time, not compile-time. Components need to be able to advertise how they are going to change before they do it. Clients need to adapt themselves to changes in components. Refactoring can play a part in this, but changes will go far beyond refactoring. They might include performance changes, for example. Suppose we decide to create a new interface for a server because the new interface can be much faster than the old. But changing the component to make the new interface fast will make the old interface a little slower. if somponents knew that the old interface was slower then they might realize that the old interface is no longer suitable, and trigger a change to the new interface.One of the thoughts I've had after the workshop is that there is a difference between DesignOfULS and DesignForULS. The first is about the general rules and practices that will lead to a ULS system when you don't have one, or keeping it going once you have it. This is where "scale changes everything". The second is about how to design a component to run inside a ULS system. The fact that you are in a ULS system has an impact on what you are doing, but it doesn't change everything. You might be able to run this project more or less like you ran the last one.
I realized that I have been thinking of the problem more in terms of DesignForULS while others have been thinking about DesignOfULS, and it has helped me to understand that we are talking about different things.