I recently had a conversation about Enterprise Architecture which went something along the lines of “how would you approach EA, if you come into a new organisation and there is nothing, no EA, no IT strategy, no documentation or other guidance”. Not having personally experienced this, or thought about this scenario, I was slightly stuck and replied along the lines of  (1) understand business strategy and operating model, (2) high level documentation and assessment of current situation and identification of gaps (3) look to resolve gaps firstly through shaping any existing IT programmes… Back came a reply, “I disagree…”, followed by a logical and sensible explanation of how that individual had begun to bring in EA. In that explanation there was a great deal of context which made me realise that in all EA work I have ever approached there always has been, and it is this that will guide you in where to start. I think the contexts where EA work is requested, or identified as needed, are well summarised in the book Enterprise Architecture As Strategy [Ross, Weil & Robertson], they call them Symptoms but I like to think of them as bad Smells:

One Customer Question Elicits Different Answers: Most probably data duplication. Start with some high-level data modelling; a quick win, to build credibility, is to eliminate just one piece of data duplication; for the longer term identify all the core data that should be shared in order to drive programs of work to rationalise the estate and, of course, ensure good ongoing governance of data.

New Regulations Require Major Effort: In my experience the root cause is Different Business Processes and Systems Complete the Same Activity (see below)

IT Is Consistently a Bottleneck: I think this is tricky but my first suspicion is there is too much re-inventing (of systems and methodologies) going on and I would agree with Ross et al that the long-term approach is to introduce standardisation. Standardisation can be applied across methodologies, technologies and ultimately in the creation of generic solutions, which can be quickly re-used. It’s difficult to pick out a specific quick win but I would look to find something that can be re-used to get work underway faster than previously experienced. Adoption of SaaS and/or PaaS could be a fast-track mechanism for standardisation but there are many pros and cons to consider.

Different Business Processes and Systems Complete the Same Activity: I would start with a business capability model to understand the extent of the problem; a quick win here is not necessarily easy, it’s simple to say eliminate a duplicate system but hard to do; longer-term develop a plan that moves capabilities delivered by IT systems to more closely match the business capability model, in that each capability is implemented in, ideally only one, but practically as few as possible, systems. Of course governance needs to review proposals against the existing map of systems vs. business capability delivered to stop problems compounding or reoccurring.

Information for Making Decisions Is Not Available: more precisely it is not available at the right time. My starting point here is to examine the flows of data, is it being held up somewhere for example in overnight or weekly batches or in waiting for external data? A quick win should be straightforward using improved technical solutions in a targeted area and, longer term, adopting those improved solutions across the enterprise.

Employees Move Data from One System to Another: aka Swivel-Chair Integration. Again this is about data-flows but this time it’s the lack of automation. The approach is similar: first these manual flows need to be understood and then technology solutions implemented where cost-effective. I know it’s easy to say but often hard to achieve when data sits in silos: the organisation will need to change its operating model to mature its IT systems architecture.

Senior Managers Dreads Discussing IT Agenda Items and Management Doesn’t Know Whether It Gets Good Value from IT: I’ll admit I’m not sure where to start on these two. I suspect their cause is one or more of the previous bad smells, anyone care to enlighten me?

The above responses are only where you could start, EA should extend to all the disciplines mentioned on a prioritised basis: there will probably be more than one smell but which is worst?

Maybe very forward-thinking organisation recognise they need EA before they smell something bad and perhaps I’ll be lucky enough to work with one sometime!

Follow

Often the Architect will come across an aspect of the organisation they have not needed to tackle in the past. This could be for a number of reasons, maybe they are new to the organisation, it was part of an acquisition, or they have simply never had time to become familiar with this part of the organisation and it has not featured in any recent projects. The architect now needs to perform some architecture archaeology. My advice is to look to the following sources:

• Existing documentation: this comes with a big health warning – it is probably wrong. Not because it was wrong when written but there have probably been changes in the meantime. If, indeed, it exists at all. If it does exist that’s a great start but it may not exist in an electronic format or in your modelling tool of choice. My advice would be to bring it into your tool of choice, copying by hand if necessary, as you are probably going to need to modify it.
• Database: if the system(s) under investigation has a database go there next. The database is probably your best bet to understand the data entities involved and the relationships between them. Some databases will include referential integrity which is the best bet for understanding relationships but if there is none you’ll need to make some deductions based on field names. Indexes may also be a clue, as they are often created in order to tune performance for joins. Stored procedures could be useful, I’ll discuss those under ‘Code’
• Users: will be able to demonstrate how they use the system(s) revealing its functional purpose, the workflows involved and participating data entities. But be warned, each individual user may not exercise all the functionality in the system so take a look for yourself at menus to see if all options and sub-options have been exercised. Even then there is no guarantee everything is covered as some systems reveal functionality dynamically based on user permissions and/or the content of records being processed.
• Developers: if the original developers are still around you’re in luck
  as you should be able to work with them to get a pretty good understanding of
  the system(s). My experience is that they don’t remember to tell you everything
  so it’s worth comparing this with at least one other source and especially if
  the original developers are all gone and its being maintained by others.
• Code: code is the ultimate authority in describing a system. I’ve bored many colleagues by repeatedly explaining that if their specification is unambiguous it can be complied. Code is the only unambiguous explanation of what a piece of software does. Now there are many coding styles and some are easier to reverse-engineer into an architectural artefact than others. If you are an Architect who does not have a development background it could be quite a tough job so get some help. Amongst the easiest style to deal with pushes virtually all the business rules logic into stored procedures which make it quite a simple exercise of looking through each stored procedure. The worst are the balls of mud which will contain multiple styles, middleware and/or languages, don’t underestimate how big a job decoding these will be.  There are tools which will help model and document the code but these will give structure rather than function and their usefulness varies greatly depending on the structure (or lack of).
• Logs/Monitoring: can be really useful to understand the dependencies between this system and others. For example a Service Oriented Architecture relying on Web Services can easily be mapped by examining the web server log files.

By combining the results from all the above it is possible to get a complete picture however you might only need to understand one aspect, like data, so pick those that make sense.

Follow