Ultra Large Scale Systems (ULS)

In the last OOPSLA Linda Northrop gave a talk on Ultra-Large-Scale systems (ULS). ULS introduces a lot of unprecedented challenges. An ULS is basically a system of systems each of large scale itself. Consider the Internet as one possible example, especially when you combine the Internet with Pervasive Computing. There are a lot of issues to be taken into account for such system. One example is the human interaction which will definitely be part of those systems. Linda motivated the problem we face with such systems with the metaphor of building cities instead of building buildings as we do today. How can architects cope with such systems? From my viewpoint, the development off ULS systems will be driven by emergent behavior and a mixture of system/software architecture efforts. By emergent behavior I address the problem that it is simply impossible to anticipate all networked entitities, especially when we consider continuous change. Thus, we can't come up with a fixed architecture. We are entering completely new areas here. There is no chance to really foresee now all the implications of an ULS on software architecture. However, we will need to introduce software/system architecture principles and guidelines that should impact the architecture. In addition, we will need to come up with some core components such as repositories, persistence stores, other kinds of central services that are essential. Everything would be initially driven by typical workflows that should happen in those systems. Essentially, we will need to start simple. Use simple abstractions and principles that can be combined to more powerful structures. The human brain is an interesting example as its main constituents are rather "simple" while its overall behavior (i.e., emergent behavior) is incredibly complex. One should keep in mind that it took mother nature millions of years to develop those brains by constantly modifying, enhancing the design, even removing old design that didn't work, until today and beyond. That implies, that we won't get it right in the beginning. Thus, ULS development will definitely need experimenting and playing around with concepts and configurations.
Swarm intelligence was a sort of precursor in that direction. Define behavior of entities as well as their interactions locally and then let the system act globally. The killer application were ant populations.

Architect always implements

This night I had a dream. I was supposed to have a surgery. Eventually, the physician came to the room. I heard him whispering to a nurse, giving her a document. It was a list of instructions he had written down. Oh, no! The nurse was going to be the surgeon!
Sounds like a nightmare. But isn't it something at least some "software architects" should be familiar with? A group of architects is specifying a software architecture. Once finished they throw it over the fence to the developers, and dissapear. I know that the comparison is like comparing apples and oranges. However, there is some truth in it.
In my last tutorial on software architecture Scott Meyers asked me why I recommend the "architect always implements" principle. And that is exactly the point. The task of a software architect starts early in the process and spans maintenance and evolution. After the strategic core design is complete, architects help to refine this core to obtain the more concrete, tactical design. And software architects always need to supervise the implementation as well as decide for tools and technologies. Find more details in my former postings.
If you consider these tasks, a software architect is only capable of fulfilling these tasks when she/he gets some implementation practice. Another issue is "eat your own dog food". You as an architect should make sure your designs work as expected by helping with their implementation. That also gives you more credibility with respect to other project members. And the other point is: how could you possibly recommend tools and technologies without practical experience? Would you trust a software architect who did not implement for the last ten years and has no clue about UML, middleware, C++/Java/.NET, Eclipse, Visual Studio, databases, Subversion, Clearcase, Maven, ... ?
Does that mean you need to implement a lot? Definitely not. It rather implies, you should implement some smaller parts that are not on the critical path because you will still have a lot of other work such as communication with stakeholders, refactorings, meetings, refinements, you name it.
Of course, it also depends on project size. In a small project with only 5 people, you cannot afford that an architect does not implement. In a large scale project with maybe hundreds of people involved , it might not be feasible to implement anything, at least not for the lead architect. However, if you're a lead architect, you should keep yourself knowledgeable by applying tools, technologies in small toy projects, and by participating in design reviews and code reviews. Of course, a software architect as I described in a former posting, is not born as such but will start as an excellent developer and then may turn into a software architect after a couple of years. Thus, she/he should like implementing, anyway.
In the projects I've been involved "architect always implements" has proven to be an excellent principle. That's the reason why I am wholeheartedly recommending it.

Architect's Project Diary

Have you ever been in a meeting where participants discussed a topic which already had been discussed several times before but no one was sure what the concrete decision had been. If yes, didn't you consider that recurring and endless discussions a total waste of your time? To be honest, this is something you will also experience in your family life. But isn't there something we can do to avoid these unnecessary discussions? As software development projects are filled with meetings, the propability of such discussions is tremendously higher which is a good force and motivation to think about countermeasures. What I consider extremely helpful, is a kind of project diary. Within a team, whenever you are deciding on important issues or on issues which you know might raise further discussions, you should document these decisions using a project diary. Mention who was involved in the decision process, what alternatives had beed discussed, which ones were ruled out and which ones accepted. Explain the "what" but also the "why" in this context. Obviously, it doesn't make sense to document everything with all details. Fundamental decisions, however, need appropriate documentation in your diary. You might structure your diary simply as a list of meeting minutes or structure it using topic areas, whatever fits your needs. The advantage of such a diary is that you can understand decisions even a long time later and explain to people why exactly that decision had been taken. Or the other way round: If your requirements or your project context have changed and you need to change previous decisions, using the diary you might get a clue which decisions must then be "refactored". Anyway, a diary is absolutely helpful, when done appropriately and without unnecessary details.