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