Web integration specifics from the SW analysis perspective
Software analysis as part of web integration (with a web integrator) differs quite markedly from the general concept of SW analysis.
A range of typical approaches and analytical outputs do not apply in this case. On the other hand, analysts must deal with issues and activities not encountered in a standard information system (IS). This article is a form of introduction to a mini-series on a topic that will include personal experiences and the author’s views on this issue.
However, in this article I will not look at SW analysis from the web integration perspective but rather do some groundwork and look at web integration from the viewpoint of classic SW analysis.
Classic SW analysis
First of all, I would like to explain a little about what I mean by "classical SW analysis".
My standpoint is based on concepts from methodologies like the Unified Process ("UP") and others. Essentially, the analyst’s work on a general level involves gathering and analysing client requirements subsequent conceptual design, and, in particular, devising a logical functional model of the created system. The specific output is either a model in a CASE tool or (much more often) analytical documents, whose core mainly consists of a use case model and an analytical class model. The use case model describes (on a logical not technical level) what the system is used for, what it does and its function. An analytical class model describes (on a logical not technical level) what the entities are like and which information (I deliberately avoid using the term "data") and relationships between them are recorded by the system, modelling the actual relationships between physical objects and notions. The other point (analytical class model) is created because the analysed system is usually an information system centred on information records.
For example, the user interface design is not part of "analysis" activity. Despite this, the GUI of an information system (which field on which screen/dialogue) is usually designed by the analyst because this issue always needs to be resolved with the client, and the person responsible for communication with the client is the analyst. In addition, the screen flow and screen content follows on from use cases and recording entities, for which the analyst is responsible.
I will leave aside the issue of analysing and designing business processes, which in general is the work of such a SW analyst, even though what is meant by "SW analysis", what is a “business analysis”, where the lines are drawn, etc., are subjects for discussion.
Development methodologies such as UP and the SW analysis idea based on them are, I would say, designed for larger projects, project teams and larger firms, where there is an interest in or a need to formalise development and assign roles among more people. Larger teams with a greater number of roles require more documents (formal outputs in general) to be produced between various stages of development. This is also required by projects that are too large to be understood by just one person.
Specific features of web integration
I will now share some ideas about the characteristics of web integration projects and web integrators. The differences compared with "classical SW analysis", which will be described later, derive from such characteristics.
Web integrators, including "de facto" integrators, started as website agencies that became involved in more complicated matters, including important functionalities or integration (implementing major processes, etc.) during work for "enterprise clients". Without wishing to sound condescending, such firms are generally overgrown start-ups, which naturally has an impact on the how they function, in both good and bad ways.
Organisation of work
One of the consequences of this is a certain level of informality and flexibility, which can be regarded as strength but also a weakness. The ability to reach agreement with a human approach, and not to boast about processes but do what is necessary, is surely appreciated by clients. But as a company grows, approaches and procedures, which worked on a smaller scale, stop doing so. The situation at the firm becomes increasingly chaotic, so the efforts to deal with the chaos must be increased too. A need arises to deal with internal processes and procedures, define roles and to check things. In my personal experience, firms that develop beyond "ordinary websites" and become web integrators go through a more or less painful transformation of internal functioning. Achieving a real shift in work organisation in projects and daily routines is long and difficult, and the battle is far from over.
To deal with the chaos, many IT companies (and certainly not only Web integrators) as well as the IT departments of their clients, make an effort to apply agile software development, in name only or in reality. Unfortunately, agile software development is like a Yeti. Everyone talks about it, everyone has an idea of what it looks like, but who has actually seen or experienced it? I certainly have not, because most people apparently do not understand the essence of agile methodologies. Rather, they interpret it as what they should not do and what is unessential, but not what should be done and what is essential. It is therefore often the case that when a firm says that it carries out agile development, it is hiding a real inability or unwillingness to do things differently other than using a chaotic and uncontrolled approach, while claiming it to be a strength. Conversely, thorough adherence to certain firm principles and rules is, in agile methodologies (for some people, perhaps paradoxically), even more important than in non-agile methodologies. Yet moving in this direction certainly makes sense.
Web integration projects are basically small. Of course, they involve "large and complex websites", but in comparison with the development of programmes such as SAP, Windows, or even just Word, they tend to be relatively minor (hundreds of man-days).
If a small or medium-sized firm does small projects it is clear that small project teams, typically of up to 10 people, will work on them, and not everyone will be working them at once. This size still allows everyone to be told everything; it can be managed down to the lowest level of detail by one person; equally one person can understand the whole solution from the perspective of his/her project role.
Typical web integration projects include various types of portals, intranets, client zones, as well as extranets used for ordering certain services, where there is a need to implement a more complex workflow and integrate it with the provider’s internal systems. A specific example is an online shop.
SW analysis versus web integration
If you have read this far, you probably will not be surprised that from the perspective of an SW analyst the world of web integration will be quite different from the world of "classical SW analysis". Where do the specific differences lie?
Fewer formal outputs
Due to the rather informal operation of the company, internally and in relation to clients, small projects and small teams, and in the efforts to be agile, there is less actual need for creating analytical models. And to some extent there is less of a need for formal documents serving as internal halfway outputs.
Less formal outputs
On the one hand, formal analytical documents need not be established at all, but even if they are, not much emphasis is placed on them. For example, usually neither clients nor developers understand UML, and they are unable to distinguish between a valid UML diagram and a "lay man’s diagram", containing intuitively used pictures of what the CASE tool offers. Therefore, in the result there is no sense in "fiddle about" with it, not to mention that smaller projects have smaller budgets and therefore there is no room for such work.
A lack of modelling
CASE tool is used only as tool for drawing a couple of diagrams, pasted somewhere "in Word". This is often the case at IT companies in general, and models are usually not created. But in WI often the essence of the issue being dealt with makes it even impossible for them to be created.
Let’s remind ourselves of the main models of classical analysis – the use case model, and the analytical class model (or the domain model and such like). The classical web integration project in a sense either connects existing systems (e.g. implementing a workflow, which runs across several systems), or presents the data recorded in them.
In delivering WI in most cases information storage is not created but information is taken from some other data storage and displayed in a web interface. Data storage is not created, and therefore there is no need to model which data will be recorded and how so, an analytical model of classes is not created.
Thus, I have just scored out one third of usual analytical work.
And what about the use case model? Basically, in many instances it would not be created either. Here it is less clear-cut why, because some degree of functionality is naturally provided even in web integration. However, here are some arguments to back this up.
What I mean by business logic is in most cases implemented in other systems, on which a new presentation layer is created. The presentation layer is the essence of the web integration project and is formed by the whole application/system, and has its own "application logic". However, the core of the application logic lies somewhere else than in implementation of business logic, which can be easily described in the use case scenarios. Conversely, to a large extent, the issue is about where and how the data is displayed and where it comes from, and therefore is mostly about the details of the functioning of the GUI, which in use case models are not described and should not be described at all. On a general level, independent of GUI, where the use case scenario should remain, it is often relatively clear what should happen, mostly "what needs to be resolved", is on a lower level of abstraction.
Greater emphasis on GUI design
I also referred to this idea in the previous paragraph. When creating a website (including complex websites, which merely "do something" and do not only display information), the issue is not about what the system does or what the user does with the system: this area tends to be far less comprehensive than "real" SW systems. Rather, it is about how exactly something is displayed and how it is worked with. In designing IS the form is probably created so that standard components of GUI are used, available in the development environment, and they are put together following logical principles while certain general standards and practices are applied. In essence the more it will be the same as what the user already knows, and the more it will be normal, the better. When creating a website, on the one hand there are much more options, but also more expectations. Everyone knows that web pages look different and are managed in a different way from standard Windows applications. Part of the task (whether explicitly or implicitly) also tends to involve a certain level of originality. In short, you pay more attention to GUI and UX than when working on IS. I would not say that it could not be done or should not be done in IS, but generally not to the same extent.
More emphasis on integration
These days, few information systems operate in isolation; on the other hand, the ratio of functions implemented by IS to the volume of interaction with other systems is smaller than in the WI solution. The latter often represents a form of presentation layer based on the client’s core systems implementing the whole data layer and most of the business logic.
Marketing instead of processes
The essence of a range of WI projects is in a place other than IS. An information system is a tool implementing a company’s processes. Of course, there are WI projects with the same focus, such as a company intranet, in which several processes running in separate systems will be joined together into one. However, many WI projects are about something else – marketing. All extranets, online shops and the like are primarily about selling something. Being an expert on online sales channels, a researcher into latest technical innovations in mobile devices and trends in their use: all of this is quite different work from "drawing ovals and boxes" in CASE tools.
Shift towards system analysis and design
We are in a situation where:
- The analyst does not create many formal documents;
- The analyst does not create abstract models of the systems;
- "What" should emerge on a more general level is often the task (also) for somebody else than (just) the SW analyst;
- The GUI and as a result most of the application logic WI solution is designed by the UX specialist (let’s not forget that business logic is now on other systems, so that the application logic of the WI project is sometimes almost only about the presentation layer behaviour);
- Integration with other system is a significant part of the WI project.
All of this leads to a shift in the analyst focus from classic SW analysis to something we could call "system analysis". The SW analyst moves away from business, which in WI projects is less about processes (a task for the analyst) and more about marketing (a task for another role). Here there is a shift to a more technical level, and in terms of the user perspective the analyst does less investigation and designing of the system but investigates it more from the perspective of other systems and their connection. Let’s ignore a situation where design starts straight away. After all, the difference between "system analysis" and "system design" is not simple, and in resolving practical problems these areas overlap considerably. But even if you stay only on the logical level during the system analysis, it will involve work other than gathering and analysis of (user) requirements. You talk to other types of people about other things, in another way.
Shift towards testing
The role of a SW analyst should generally include validation of the project outputs, and an assessment from a specific overall view, of whether what has been established should have been established. No specification is ever completely clear-cut. There are always several ways of creating something that is not contrary to the specification but not what the client wants. Ideally, verification, i.e. comparison of the result with the specification, is carried out by the testing team (among other tasks).
Despite the fact Lundegaard (my current employer) is making specific efforts to apply a different approach, I venture to say that in small projects at small firms, in teams made up of a couple of people, an additional tester is usually missing. And even when the testers are available, they do not carry out real testing (preparing test plans, test scenarios, subsequent work with a tool for reporting bugs…). Testers just do more clicking than developers. In such a situation it is often true there is no other option than for the analysts to check compliance with the specification themselves. Because the projects are relatively small this is not a problem, and on the other hand actually effective. From the analysts’ perspective it is ultimately often easier (in particular, when they have the idea in their heads, including details that they have not written down on paper) to make comparisons with the specification themselves than to explain to the testers what exactly the testers should investigate, how and with what results. This is especially true, when the testers do not actually know about the project and someone goes to see them just before the deadline and says, “so let’s test it". Real testing actually involves a proper tester in the project, and sufficiently in advance. But such work makes up 30% of the budget (but which must not be used as a reserve for extending implementation), and clients would not pay.
In this article I attempted to outline the aspects of the environment in which the SW analyst works in a WI project. In other articles I will develop these considerations further and will focus on how an analyst could work in such an environment, and how he or she, in my opinion, should work. In this article, when comparing procedures/outputs of classical analysis, attention was paid to what is not done and what cannot be done in WI projects (or what can be done but in my view does not make sense). In contrast, in the next article we will look at what I believe can and should be done in SW analysis in WI projects, an area that for many is hard to grasp.