jump to navigation

Why do we need architects anyway? February 10, 2013

Posted by Chris Eaton in architect, architecture, architecture method, artitecture, careers, communications, competitive strategy, EA, Enterprise Architecture, IT Architecture, IT strategy, methodology, methods, people.
Tags: ,
add a comment

I recently spent a very interesting day with IBM and the Corporate Executive Board on the future of architecture. Very interesting, very thought provoking. On the back of this, i have put together this paper Why do we need IT architects anyway?

‘The pervasive nature and continual improvement of technology in daily life presents vast opportunity but it is not always easy to see it. Armed with the right skills, methods and tools the IT architect can help you see the possibilities and exploit them’

Thoughts and comments are welcome. And i am very interested in how you live up to this vision…

Advertisements

speak in a language others can understand October 8, 2008

Posted by Chris Eaton in communications, EA, people.
Tags: , , , ,
add a comment

I came across a very good article here named EA Demystified. One of the salient observations is the use of language which is only comprehensible to people familiar with EA. Actually, I have stopped introducing myself as an Enterprise Architect because I receive such blank looks, and even if someone has an appreciation of the term ‘enterprise architect’ they ask for a clarification since it can mean so many things.

TOGAF in particular needs a makeover in this space using terms like ‘Enterprise Continuum’ which fails completely to communicate what it is, and presents a complete barrier of understanding to any but those familar with TOGAF. This is a defnite communication fail.

Below is another example i came across today is in wikipedia in the entry for Enterprise Architecture – here . ‘One method, described in the popular TOGAF architectural framework, is to develop an Architectural Vision, which is a description of the business that represents a “target” or “future state” goal. ‘

Well, in my opinion someone completely misunderstood the use of ‘Architectural Vision’ in TOGAF which is about selling EA and obtaining Buy In from stakeholders to start and continue to support EA. In TOGAF Target Architecture is about future state architectures, not Architectural Vision but im not here to criticise the wikipedia entry, my critism is that TOGAF once again uses language which is unclear, open to interreptation by EA practitioners let alone the uninitated in EA.

so some very simple advice, use simple language in communications.

for the enquiring mind, i introduce myself as ‘working in IT Strategy’ , which i think is a reasonably comprehensible to the average joe and certainly recieves a much more warm reception than an Enterprise Architect. I hope one day I can say i am from the ‘Business and IT Strategy but my team is still seen largely in the technology space – for now..!

IT Architecture Diagrams II – Recommended Format and Notation August 1, 2008

Posted by Chris Eaton in communications, IT Architecture, methodology, methods, SAP.
Tags: , , , , , ,
8 comments

**** Click here to download the full example ****

after interest in the last post on architecture diagrams I am writing this description of the architecture diagram notation I have been using for several years.  This format has stood me in good stead for a number of large multi year projects with budgets from $10 to $50 million a year upwards.  In my current role as Chief Architect of the second largest project in IBM Globally we have a project budget in the half billion dollar range, we have hundreds of components and interfaces and the diagramming technique explained below is the one which I have enforced throughout the project, we successfully delivered our targets in 2007 and are on track for this year. It works. It scales. I do not know of any well thought through alternative. Any suggestions for improvement are welcome! I have also provided a download of the example discussed here – Click here to download the example set of Architecture Overview Diagrams – this also includes the additional information I recommend goes with the diagrams.

Example Diagram

I will start off with this relatively simple example (click to enlarge)

This architecture shows an SAP system communicating to a number of other systems. Each rectangular box represents a component and each component is uniquely numbered for ease of reference both when talking about this diagram but also when you create other artifacts you can reference the component using this number. The arrows shows the existence of a data flow between the systems, and again each data flow is uniquely numbered for ease of reference.

Level of Decomposition

Just a note here, when you create Architecture Overview Diagrams you will have to choose the level of decomposition. Look at the SAP box for instance – SAP is made up of many components like the database, SAP GUI, SAP NetWeaver, SAP Portal, etc. For the purpose of this overview diagram is simpler to abstract SAP into one box although really is has many components of interest. I have chosen this level of decomposition for the specific purpose of this diagram. If you abstract components like this you should consider adding another diagram which decomposes these more complex components to a further level of detail down. Have a look in the example presentation with this post. I have a separate diagram just to describe the SAP stack and which SAP components are used. On these kinds of diagrams you should not need to decompose to too fine a level of detail. If you have classes, and operators you are at too low a level for this kind of diagram, that is when you should switch to other diagramming techniques like UML.

Component Types (click to enlarge)

The different colours of the components do have a meaning and each box should be given a meaningful name.

The first box type in dark blue box is a component which is owned and is specifically part of your project scope (i.e. you own the deployment or change to this component), this maybe new or it could be a change to an existing component.

The second box type in grey is a component someone else owns, but no development is required at the other end of the to allow the transfer the data. This is often the case when you develop an interface which fits exactly the format which the other party is expecting without alteration, typically when an integration already exists and this new system is simply replacing a direct copy of what was already there. Small configuration changes might be necessary at the other end to accept the data from your source but this is assumed to be trivial. The implication of no development is that the integration should be relatively straightforward particularly from a project management point of view since the dependency on the other party is not significant.

The third type in light blue is where the other party does need to change and develop something to either send or receive data which was never sent or received before, or an alteration to the integration method. The implication here is the dependency between your system and the other party is significant. Their implementation schedule will need to match your dates for system integration, user testing and production deployment and production cut over.

The last type in light blue with a red surround is a component which sits outside the firewall, all the other component types are assumed to be with your internal network. This is important because the security necessary to talk to external system is often much tighter than communicating with other systems on your internal network.

Arrow Notation (click to enlarge)

First of all the direction of the arrow is important. It show the logical flow of the data.

The solid arrow is a direct flow of data. This is always automated, and alway system to system. The method of exchange is not explicitly described and further explanation will be required. If you look at the example deck the interface mechanism has a textual description and the method of transport. It could be any number of methods like ftp, MQ, JMS, REST, HTTP, SOAP, etc.

The dashed arrow is an indirect flow of data. This will require biomechanical automation (a human) to complete. Typical examples are uploading a spreadsheet or running and exporting a report which is then sent somewhere.

Lastly the red circle is used to show who is the initiating the transaction. The direction of the arrow shows the logical flow, but not who starts the transaction.

So in the first example the data is flowing from System A to B, but System B is the system which initiatives the data flow. This could be calling a service call, or an ODBC connection to System A made by System B to retrieve the data.

The second arrow shows data flow from System A to system B, and it is System A which starts the transaction. A Message (MQ, JMS, etc) would be an example of this, as is a batch interface where System A create the batch interface and sends it to System B.

Other Notation (click to enlarge)

These two boxes are used to uniquely number every single component and interface in the diagram. Diagrams may span several pages, uniqueness should be preserved across an entire architecture.

One improvement I will create to a colleague, Steve McKim, is when a component acts as a passthru, like MQ, or an ftp server label the boxes 6a, 6b, etc. This makes the diagram much easier to understand when the same data is flowing through multiple components.

Diving into the Example Diagram

Lets now take a couple of interfaces from the example diagrams and explain them, the first is generating a message from SAP and passing it to Websphere Message Broker

So you can see we have three components, and 2 interfaces. SAP generates a message and send the message to MQ. MQ is simply a pasthru and automagically send this to Websphere Message Broker. You can see the use of the 6a/6b notation on the interfacing number. The data is unchanged by MQ so it makes sense to show that the data from SAP is being moved to WMB unaltered.All of the arrows are solid so all of this is automated. Since this is a messaging model, SAP initiates the data flow to MQ, and MQ in turn initiates the data push to WMB. for simplicity I have left off what WMB does then. WMB is IBMs heavyweight messaging solution (ESB) so you can safely assume this does allsorts of data transformations, logging, and connections to allsorts of systems via any number of protocols.

The diagram itself is not sufficient to explain everything to the inquiring mind. Why SAP is generating this message is unexplained, how does SAP connect to MQ? SAP does not have native MQ connectivity nor does it generate MQ headers automatically so how is this done? All of this kind of thing needs to be covered in the detail documentation. In IBM and ITIL language this is a Component Model this is somewhat akin to good old internal and external design documents. I would also advocate proving a short explaination with the diagram and I have provided this in my full example.

The second example is a less clean indirect integration.

In this example a spreadsheet is created or updated somehow from SAP. The use of the dashed line indicates this is only partially automated. In this case a user is exporting a report into a spreadsheet possibly onto a server (more than likely their laptop/PC) and then using that spreadsheet as the data source for a Lotus Notes database. They are probably using an Agent in the Lotus Notes database to find and import the data.

Just the same as the first example, the diagram does not explain all the detail, but it does communicate the general data flow and you can make reasonable assumption about what is happening. Further detail is needed to fully explain the flow, what is happening and why. The detail must also cover other considerations such as how the spreadsheet is secured if it contains confidential information.

And Finally…

Remember that these diagrams are a communication method. In any good communication you know your audience and you tailor your communication to them. This notation is very good for communication with other architects and developers at a project level but also at Architecture Review Boards. I have also used these with auditors who often have technical leanings. This format probably isnt what you want to show an executive 🙂

I said it a few times already these diagrams are useful in their own right but you will need further detail documentation to explain more about what is happening and why, particularly to developers. A crucial piece of the notation is the unique numbering format which allows you to tie any given component or interface shown in this diagrams to the detail documentation.

looking for mentees July 18, 2008

Posted by Chris Eaton in communications, IT Architecture, mentoring, people, Uncategorized.
Tags: , , , , , , , , , , , , , ,
1 comment so far

I am looking to mentor people in IT architecture. Part of the Open Group IT Architect Certification (ITAC) requirements is ‘giveback’ to the profession and mentoring is one of the most important. I have experience as an application, integration and enterprise architect with particular technology experience in SOA and most IBM software

Mentoring is not just about technology, it is also about careers, coaching and soft skills…

I also have quite a few certifications which i can help with too, including TOGAF, ITAC, Sun Enterprise Architect and Project Management Professional

I am also a dab hand at reworking CVs and Resumes…

If you are interested in discussing mentoring please contact me at gruffoot@gmail.com

IT Architecture Diagrams July 17, 2008

Posted by Chris Eaton in communications, EA, IT Architecture, methodology, methods.
Tags: , , , , , , , , ,
8 comments

we are coming to the second wave of a major project i am working on which is deploying to over seventy countries. I asked my architecture team to go an find out about the existing architecture of the next set of countries, and some bright spark asked what tool and standards we should use to document this.

For the wave 1 countries I invented an architecture diagramming standard using powerpoint *update* I have written a full detailed explaination of his notation -> here. The major thrust of the architecture work is integration oriented. I’m afraid UML is too detailed, and does not have constructs which show the logical flow – you have to go down to integration diagrams for this. In my mind UML diagrams =  the domain of an application architect and possibly an integration architect. It is not the domain of an enterprise architect or even a chief architect.

I know from prior analysis that there isnt a standard for this higher level diagram. In IBM method terms this is called an Architecture Overview Diagram. In essence  an Architecture Overview Diagram is a diagram which shows an architecture for a specific audiance and/or purpose. In my case the audience is other architects, with the purpose of talking about all of the significant components and all integration points within our direct control, and integrations with systems we have a dependency on; either to retrieve data from them or send our data to them.

In my model each major component is named on the diagram and uniquely numbered. a component could be something large like SAP, or even an abstraction and a collection of components – again SAP is like this, you have the GUI, the backend, you will probably bucket the database as SAP even though it isnt really SAP (in my case DB2).Or, it could be something very granular like a single service. The level of detail in the diagram is dependant on the audience, but none the less powerpoint is the tool of choice 😦

IBM itself uses Qualiware to document its own ‘to be’ Enterprise Architecture. I am not keen on this tool personally.  Maybe it isnt so much how the tool works perhaps it is the way we use it. I can argue that we mix business flows with integration flows and there is variation in the level of detail and what is shown amongst the various business units who document their as-is architectures.

In summary, there needs to be a standard for architecture charts. There needs to be a standard for enterprise architects, there needs to be a standard for chief architects, there needs to be a view for application/integration/infrastructure/network/data architects. It is astonishing that powerpoint is the major tool of choice. There needs to be referential integrity between these diagrams. Today this is manual, it is not enforced by the tooling.

is someone listening and fixing? 🙂 i can only hope!

EA communications plan July 11, 2008

Posted by Chris Eaton in communications, EA, IT Architecture, methods, people.
Tags: , , , , , , ,
add a comment

Communications planning I feel is an oft forgotten part of an EA, even a mature EA. Often, communications is an ad-hoc affair, but planning who you communicate to, what to tell them, when to tell them and then executing against that plan *should* be a substantial part of a good EA practitioner. After all, communications in one form or another is what you are going to be doing 90% of the time.

Communications can take different forms, it could be a regular monthly email, or regular calls to disseminate information, a one on one call, a group call focused on a particular decisions or a website for individuals to find the information themselves. The audience of a particular communication is very important, a is the timing of the communication.

Who, What, When – A communications plan says WHO you are going to communicate with,  WHAT you are going to tell then, and WHEN you are going to tell them.

WHO says that different roles and people need to hear and know about different information. Classic best practices say that executives for instance need to hear and know about different things from solution architects and again there are further role like project managers who should be aware of aspects of the EA like standards and will need to ensure compliance but don’t necessarily understand how the technology needs to work for that compliance

WHAT says what you are going to tell them based on their role, a CIO probably expects a monthly high level update in less than one hour, a solution architect, or group of solution architects may need a one hour meeting to discuss just one new standard which you have introduced, other roles like project managers who own project which need to comply to EA only an awareness.

WHEN says that communications need to arrive at different frequencies for different roles, monthly, weekly, yearly? When can also be triggered, for instance if a requirement changes, or a major event takes place which alters, or could alter, the EA such as a merger of your company or of a competitor, or a change in business strategy, or perhaps even a Black Swan.

In summary most communications should (must) be planned for a specific audiance, of course there are times when the unexpected happens and communications takes the form of hastily scheduled calls or meetings, but the vast majority in a mature EA should be planned.