SolNet, with a reduced staff and an absence of Sun hardware specialists, is still responding to tenders and revising some to take account of the distancing of the contact with Sun, says solutions architect Ido Lelie.
In a sense, it also leaves the former local Sun agent with greater freedom in making proposals, particularly at the level where he works, Lelie says. “Suddenly, we can architect a proposal any way we like,” he says. The company is no longer influenced by the need to work with Sun hardware and software platforms.
That said, there is less of a difference than there would be with another hardware partner because of Sun’s commitment to open systems, he says.
Lelie was speaking before a talk covering the role of the IT architect and his/her relationship to the customer and to the other disciplines of the IT world, at the NZ chapter of the Worldwide Institute of Software Architects (WWISA).
The architect, thinking of a solution at a high level and for the long-term, is often seen as meddling in the perceived priorities of the specialist “engineers”, he says. On the other hand, the architect is dependent on the knowledge of these engineers, which makes for a delicate relationship.
The relationship with the customer is scarcely less uneasy. When infusing an architecture into an RFI or RFP response, Lelie says, the architect and colleagues often find they are advising the customer what they need, which can be very much at variance with what they thought they wanted.
His core topic for the address was “Architecture, art or science?” The answer is, perhaps inevitably, some of both. The architect must work within tight constraints, but employ flexible thinking in elegance of design and the reflection of function in form, which are the province of art.
Lelie considered the shape of a coherent framework for devising an architecture. He centred on a scheme developed by Philips, in his native Holland, leading a design through the stages of:
- customer objectives — the business drivers and value chain
- application — the evolution of an entity relationship model within the context of stakeholders’ concerns
- functional — consideration of use cases (normal and “worst possible scenarios”), the commercial logistics and the mapping of technical on to business functions
- conceptual — function and data decomposition
- realisation — construction of the final design within the constraints of time and budget.
Showing a point of view that may worry the more methodical of thinkers on IT architecture, Lelie referred his audience to Philips’s more extensive considerations of architecture methodology, which it has christened after that most fluid and daring of architects, Antonio Gaudi. The Gaudi project is here.