2008/5/28 Nick Gall <[EMAIL PROTECTED]>: > On Wed, May 28, 2008 at 11:19 AM, Steve Jones <[EMAIL PROTECTED]> > wrote: >> Now this I agree with and its quite a nice definition. How do you >> think things like business strategy would link in (its a sort of >> requirement but not as we know it Jim). I'd also be inclined to >> broaden system implementation into IT delivery as I think that >> architecture should focus at least as much on the operations and >> organisational effectiveness of IT in meeting the business objectives. >> This is also important in a distributed Services estate as it needs >> to cover the interaction between services whether inside or outside of >> a companies domain. > > > Thank you. And good catch on the delivery/operations omission. Here is a > revised version: > > Architecture is the process of translating initial and ongoing requirements > into effective system implementation, operation, and change by creating, > communicating, and improving the key principles and models that describe the > system's desired state and enable its evolution. > > As for linking to strategy, I think "requirements" is broad enough to cover > even strategic requirements, but if you wanted to add that explicitly to the > definition, I wouldn't object. As for the issue of whether the system in > question crosses company boundaries, the definition is neutral with regard > to it. Notice that the definition does not say where the initial and ongoing > requirements come from. They could come from a single company or from a B2B > consortium.
The two bits of requirements and system are the bits that might need refinement here. Requirements tends to be (we can use it in other ways but...) Use Cases, specific request etc rather than business objectives and company strategy. As an example of this when I worked with a company who wanted in 2000 to "get on the Web" we found that for their market the web was only one element and the major one was that they had a non-Web IT access to every one of their customers and investment in that channel would be much more effective. This to me was classic architecture as it took an overall corporate goal (sell more stuff) and a business requirement (we've got to have an e) and then created an architectural solution that leveraged these in a new way. The level of woolliness in the statements I was given was exactly what enabled me to create the requirements in a way that was successful. How about objectives instead of requirements? It implies (to me) both the specific (requirements) and the generic (strategy). The second one is system. To me that implies a black box of IT. Clearly system can also be used to describe an eco-system of collaborating services but that isn't how lots of people will read it. How about replacing system with ecosystem? That way it can cover both the IT and non-IT elements and implies some form of holistic view. > > -- Nick Steve > >
