Embed Size (px)
Citation preview
Deliverable 1 and 2
INF5890
Group members:
Philip Strøm Anthonisen
Andreas Jensen Gjellesvik
Kristine Helen Lyngholm Næss
Faculty of Mathematics and Natural Sciences
University of Oslo
Table of contents
1 Introduction ................................................................................................................. 1
2 Oslo Stock Exchange in a nutshell ................................................................................ 2
2.1 Historical perspective ................................................................................................... 2
3 Organizational structure .............................................................................................. 4
3.1 Business as a whole ..................................................................................................... 4
3.2 IT-department .............................................................................................................. 4
4 Key systems and interconnections ............................................................................... 7
4.1 Core system .................................................................................................................. 7
4.2 Other key systems ........................................................................................................ 8
4.3 Interconnections and shared depositories ................................................................... 8
5 Decision rights ........................................................................................................... 10
6 Possible improvements .............................................................................................. 12
6.1 Business and IT principles .......................................................................................... 12
6.2 Governance Arrangement ......................................................................................... 14
6.3 Project method .......................................................................................................... 17
6.4 DevOps – an alternative approach to projects and project management ................ 18
7 Concluding remarks ................................................................................................... 23
References ........................................................................................................................ 24
Appendix A – Interview guide .............................................................................................. I
Appendix B – Interview transcription ................................................................................. III
Appendix C – Project charter ............................................................................................ XV
Appendix D – Stakeholder management strategy ........................................................... XVII
Appendix E – Communication Management Plan ........................................................... XVIII
1
1 Introduction
When we started this assignment we initially suggested three candidates and decided by draw
who to contact. 99X, a company one of the group members work in, became the result of the draw.
We sent them an e-mail and waited a week and a half for an answer, before deciding to send out
multiple other requests. The companies we reached out to were the following:
99X
University Center for Information Technology (USIT)
Direktorat for forvaltning og IKT (Difi)
Oslo Børs ASA (Oslo Stock Exchange or OSE)
We quickly got a reply from Lars Oftedal at USIT, but when it became clear that two other groups
also had picked USIT as their subject we decided to look elsewhere. Difi also replied quickly, but
referred us to two other people in the organization. It took eight days to get a reply from one of
those people. In the meantime we got a positive reply from Oslo Stock Exchange and decided to
do the assignment on them.
Our contact, Kjetil Nysæther (CIO), was eager to talk to us. However, he could not provide any
secondary sources for us to study. We assumed the reason for this was information security,
which they take very seriously. Their key systems are highly critical; without them all trade can
stop. They combat multiple hacking attempts daily, and revealing too much information can pos-
sibly make it easier for hackers to break in. This meant our secondary sources were limited to
what we could find publicly available on the OSE website, which we later discovered was quite a
lot.
In the coming chapters we first provide a short presentation on OSE (chapter 2), followed by their
organizational structure (chapter 3), key systems and interconnections (chapter 4) and decision
and input rights modelled using the Governance Arrangement Matrix (chapter 5). Possible im-
provements to governance in OSE is presented in in the following chapter (chapter 6), and at last
we offer some concluding remarks (chapter 7). The interview guide and transcription of the in-
terview are added as Appendix A and Appendix B. The interview was conducted in Norwegian, as
both interviewers and interviewee were Norwegian. The project charter is added as Appendix C,
stakeholder management plan as Appendix D and communication management plan as Appendix
E.
2
2 Oslo Stock Exchange in a nutshell
Oslo Stock Exchange was established in April 1819 under the name Christiania Børs. 1 They have
approximately 85 employees2 and had an average daily turnover of 4.1 billion NOK in 2016.3 For
obvious reasons their profit is a lot lower; the result was ~154 million NOK in 2015.4
OSE is a company fully owned by a holding company (Oslo Børs VPS Holding ASA). The holding
company is owned mainly by Norwegian and foreign institutional investors, brokerages and in-
vestment banks, some listed Norwegian companies, pension funds and other private companies
and people. No single stockholder is allowed majority ownership. Their biggest current stock-
holder is DNB (Den Norske Bank), which owns approximately 20 % of the stocks.5
The regulatory obligations of OSE are more than a handful, and we will not list all the regulatory
instruments they need to comply with. Instead we offer a list of main regulatory instrument
types:6
General acts most companies must comply with (e.g. the Working Environment Act and
the Accounting Act).
Specific acts covering listed and publicly tradeable companies.
Specific acts covering financial institutions.
Specific acts covering the trade of financial instruments (also known as securities).
Specific acts covering the exchange companies and companies who offer trade of finan-
cial instruments.
One of the main regulatory obligations of OSE is market surveillance,7 e.g. to prevent unlawful
insider trading.8 They have a legal duty to report suspicious market activity to The Financial Su-
pervisory Authority.9 In addition, they are subject of supervision from the same agency.10
2.1 Historical perspective
In 2001 OSE changed from being a self-financed foundation with market monopoly to becoming
a limited company, and then privatized and exposed to competition.11 This organizational change
set higher demands to profitability and cost-effectiveness. At the time they had a lot of different
1 Oslo Børs (a). 2 Oslo Børs VPS. 3 Oslo Børs (b). 4 Purehelp. 5 Oslo Børs (a). 6 Oslo Børs (c). 7 Oslo Børs (d). 8 Oslo Børs (e). 9 Børsloven § 45. 10 Børsloven § 44. 11 Oslo Børs (a).
3
systems built on different technologies, with a lot of expensive shelfware. To increase effective-
ness they started a standardization process, where they inter alia standardized on Windows as
operating system, SQL-server for databases and Java as development-environment. They started
developing most systems in-house and the old shelfware was phased out and. Their trading sys-
tem was outsourced to London Stock Exchange (LSE). As a result of the changes, man-years in the
IT-department was reduced from 43 to 24. The situation has not changed during the last three
years.
4
3 Organizational structure
3.1 Business as a whole
OSE is a business comprised of several departments. Each department has an assigned field of
operations related to each major function of OSE (see figure 3-1.) Each department is assigned an
executive director charged with the chief responsibility of running the department. Each execu-
tive director report to the director of the OSE. The executive directors have a seat at the executive
committee at OSE, where the all the executive directors participate as equals. The executive com-
mittee process suggestions and authorize projects among other things.
Each department are organized into sub groups with a defined responsibility for certain processes
and tasks within the department. An example of this can be seen in figure 3-2 which illustrates the
IT-department and its underlying sub groups. This will be further expanded upon in chapter 3.2.
Figure 3-1
3.2 IT-department
As discussed in the previous chapter, the IT-department is one of six departments (excluding the
director) at OSE. The IT-department is divided into five subgroups. We were not able to obtain
any documents pertaining to the exact tasks and mandate of each group. What follows is a short
5
explanation of the tasks of each group based upon the information gathered through the inter-
view:
Chief of trade systems
o The person responsible for the trade systems, which are provided by an external
actor (see Key systems and interconnections). The chief of trade systems is keep-
ing up to date with any changes in contracts related to the outsourcing of the
trade systems. This position is necessary because any changes in the outsourced
system could have major effect on other IT systems and clients.
Development
o This group is tasked with developing new systems and solutions in addition to
managing the existing systems developed in house. There are quite a few sys-
tems to manage. This is partly because of security concerns, and connected to
various legal regulations and requirements.
IT architect
o In similarity with the Chief of trade systems, the IT architect is more a position
than a group. The person in this position is responsible for managing the IT ar-
chitecture and reports to the CIO.
Maintenance and infrastructure
o This group is tasked with the day-to-day operations of the IT-systems. The group
is also held accountable for the IT infrastructure. Large, principal decisions re-
garding infrastructure (i.e. Investment in new infrastructure) however, must
gain authorization from the board of leaders.
o To accommodate the needs of day-to-day operations the maintenance and infra-
structure group has organized a subdivision dedicated to helpdesk tasks.
Project
o The OSE usually has at least 3–5 projects running simultaneously. This supports
the product oriented business goals of OSE. The project groups are temporary
constellations made up of different people from every department of OSE
o Unexpected errors could potentially have severe consequences. A good environ-
ment for continuity is a linchpin in OSE. That is why the project group has its
own testing division. This division is tasked with ensuring that every project is
sufficiently robust pending its release through testing.
6
Figure 3-2
OSE can be described as a hierarchical organization. Decisions regarding day-to-day operations
are made at the lower levels. The IT director said this was linked to proximity in the interview.
The person that is most closely related to the task at hand, would probably make the better deci-
sion on this matter. Any major changes or projects would however need approval from the IT
director or the board of leaders, thus making the business a hierarchy. However, the IT director
emphasizes that the reality is slightly different. Since the organization is of a rather small size, the
relations between the departments (both horizontally and vertically) are not very formal. Accord-
ing to the IT director this makes it easier to realize ideas that are conceived at subdivision levels.
If the ideas are well grounded and the preliminary work is thorough, the ideas does not have to
pass through a lot of bureaucratic processes to get approval.
7
4 Key systems and interconnections
The figure below illustrates the key systems of OSE and how they are interconnected. This illus-
tration and the further descriptions of the systems in this chapter are based on the information
gathered from the interview with the CIO of OSE. We chose to limit this chapter to a brief overview
of the main systems of OSE, based on the information given in the interview. We would like to note
that more detailed information about trade systems and technical documentation are available on
the website.12
Figure 4-1
4.1 Core system
The business-core of Oslo Stock Exchange is strongly reflected in the systems and their organiza-
tion. Because OSEs foremost business-function is to offer a trade service this is their main product.
12 https://www.oslobors.no/Oslo-Boers/Handel/Handelssystemer/SOLA https://www.oslobors.no/Oslo-Boers/Handel/Handelssystemer https://www.oslobors.no/Oslo-Boers/Handel/Handelssystemer/Millennium-Exchange/Teknisk-dokumentasjon
8
Accordingly, the key system of the organisation is the trade system, which the trade service is en-
tirely dependent on. While OSE are careful to develop, run, govern and maintain most of their
systems in-house for security and ownership reasons, the trading system is an exception.
Referred to as the core system of OSE, the trade system is outsourced to London Stock Exchange.
The system, called ”Millennium” is developed by a company by the same name – Millennium IT in
Sri Lanka. As figure 4-1 shows, the trade system really consists of two separate systems – one
system for stocks and interests, and another system for derivatives. These trade systems are part
of a strategic partnership with LSE – OSE having leased a spot for their systems in the LSE trading
system. Through this arrangement OSE have the trading systems run and maintained by LSE, and
the systems are physically based in two data-halls in the London-area. Because all other systems
are linked to the trade system, any updates to the trade system will require adaptations to all
internal systems.
4.2 Other key systems
4.2.1 Index calculation systems
Beside the core trade system, there are other key systems run in-house at OSL. One of these central
systems is the downstream systems, which operate index calculations. As an index indicates the
rise or fall of all stocks put together, these systems are vital for trading at the Stock Exchange. The
indexes are calculated at OSE based on the data coming from the LSE trade systems. The results
of the calculations are then fed back into the LSE trade system, as shown in figure 4-1.
4.2.2 News service system
OSL also have a news messages system. The system is a news service, allowing the companies
connected to OSL to send out messages about for example profit warnings and new contracts to
the other companies. This system is central in the way that it ensures that the companies and
brokers are able to make their decision based on validated, up-to-date information.
4.3 Interconnections and shared depositories
OSE have several ways of interconnecting and sharing data between their systems. In the follow-
ing, we give an overview over the tree components highlighted by the CIO during the interview.
4.3.1 Real-time message bus
The real-time systems of OSE are connected through a real time message bus. This allows the sys-
tems to publish and subscribe to messages from the bus, giving OSL a “message-bus-oriented-
9
architecture”, following the principles for Hub and spoke architecture. The service is described by
the CIO as the “nervous system” of their real-time systems, as it ensures communication between
the systems, as seen in figure 4-1.
4.3.2 Backbone network
The backbone network are, as can be seen in figure 4-1, the infrastructure that enables communi-
cation between OSE and LSE. The backbone network runs between OSE and LSE as a dedicated
network on three separate lines. Dedicated to communication between OSE and the LSE trading
systems, the system is of major importance to the trade, and is therefore made completely sepa-
rate to ensure redundancy of the systems.
4.3.3 Databases
The systems and shareholders are dependent on having the right information available in shared
repositories. OSE makes use of two databases for the purpose of storing and sharing; one marked
database and another database for analysis.
10
5 Decision rights
In the following we explain how decisions are made at OSE and who makes them. Below we pro-
vide a table presenting our understanding of OSE’s IT Governance Matrix (table 1).
Neither the business-side nor the IT-side have developed explicit principles they model their work
after. Nevertheless, the CIO feels that the way the IT-department work is very much aligned with
the business goals. They rarely experience conflicts between the business-side and IT-depart-
ment. We believe there are multiple explanations for this. First, all employees acknowledge the
importance of IT for OSE; without it there would be no trade of securities. This is also reflected in
the organizational structure, where business departments and IT participate as equal partners in
the executive committee. Second, the company is relatively small. Eighty-five employees in total
allows for short decision-routes and a working environment where most employees know each
other. Third, all business systems have a business-side owner, which means that the business-side
cannot distance themselves from the systems. This also means they have to cooperate with the
IT-department when a new system is developed. Overall, this seem to make it possible for IT to
be integrated with the rest of the business to a high degree, and thereby to work towards the same
goals, without explicitly defining either business-principles or IT-principles.
Input for decisions about IT architecture comes from the IT-architect. He or she makes a recom-
mendation and presents it for the CIO. The decision is then made by executives in the IT-depart-
ment. Similarly, input for decisions about IT infrastructure comes from the IT maintenance and
infrastructure department, and decisions are taken by the IT-executives.
Input for decisions about business application needs comes from the director of the relevant busi-
ness unit and the CIO. Together they make a business case that the CIO presents in a meeting with
the executive committee, which then make a decision. Similarly, the executive committee also
make decisions regarding IT investments, but input comes from executives in the IT department.
11
IT principles IT
architecture
IT
infrastructure
B. application
needs
IT investment
I D I D I D I D I D
B. monarchy
IT monarchy
Feudal
Federal
Duopoly
N/A
Table 1
12
6 Possible improvements
6.1 Business and IT principles
The most obvious room for improvement we found during our interview with OSE was in their
lack of business and IT principles. Weill & Ross claims that “study after study demonstrates that
enterprises achieving superior business value from IT have a small number of clearly articulated
IT principles.”13 We cannot exclude the possibility that business principles existed, but if they did
their CIO was not informed. This seems unlikely, as their executive committee seemed to be a
tightly woven group.
The only principle-like business statement we have found for OSE comes from the “about” page
on their website: “The main objective of Oslo Børs [OSE] is to be the central marketplace for listing
and trading of financial instruments in the Norwegian market”.14 However, it is also possible to
extract business principles from two other text boxes on the same webpage:
Oslo Børs provides access to capital through listing on international and attractive market-
places and make it possible for purchasers and sellers of securities to carry out their transac-
tions in a rapid, efficient and secure manner. Market surveillance, quality assured processes and
consistent application of the regulatory framework ensures that the marketplace offers a secure
and reliable environment for all participants.
The Oslo Børs marketplaces enjoy a unique position for companies in the energy, shipping and
seafood sectors. Companies from all over the world turn to the Norwegian market to raise cap-
ital, access liquidity for their shares and benefit from a range of world-leading investment re-
search coverage available in Oslo. Investors look to the Oslo market for access to high-quality
Norwegian and international companies.
If we convert the quotes above into business principles it could look like those below. The num-
bering does not relate to priority, but merely makes it easier to refer to certain principles later on.
1) Be the go-to marketplace for listing and trading of financial instruments in Norway.
2) Be the go-to marketplace for listing and trading of financial instruments in the energy, ship-
ping and seafood sectors worldwide.
3) Offer capital through listing in international and attractive marketplaces.
4) Offer rapid, efficient and secure trading services.
5) Excel in compliance, market surveillance and cooperation with supervisory authorities.
13 Weill & Ross (2004) p. 27. 14 Oslo Børs (g).
13
The following IT principles are developed from a combination of the extracted principles above
and information we gathered in the interview. In other words, they are meant to reflect the cur-
rent situation and focus areas for the use of IT at OSE. The improvement lies in the development
of the principles themselves.
1) Develop solutions to make listing processes more effective.
2) Offer attractive trading products worldwide, with focus on speed, UX and easy integration.
3) Simplify IT architecture and infrastructure as much as possible.
4) Offer full redundancy and a high level of security.
5) Develop solutions to make market surveillance more effective.
6) Provide thorough documentation for all systems.
To be a go-to marketplace (cf. the first and second business principle), OSE must make themselves
internationally attractive to be listed on. We get the impression that listing a company can be a
slow, cumbersome process. For example, getting listed on London Stock Exchange can take 24
weeks.15 Getting listed on OSE seems to be more effective, though, at just 8 weeks.16 Having a
shorter listing process than competing stock exchanges can make OSE more attractive, as long as
the process is proved equally secure. From an IT-perspective it is important to make sure that IT
does not halt or slow down the listing process in any way. It would also be useful if IT could help
speed up the process, e.g. by developing tools and making them easily available to relevant parties.
The second IT principle is meant to make it attractive to trade on OSE (also cf. the first and second
business principle). We hope the inclusion of “worldwide” make IT managers look above and be-
yond the local market when developing new solutions. This implies that OSE should have an over-
view of products offered by competitors in other countries, to know what they are up against. We
have also included a set of focus areas. Speed and good UX (user experiences) is likely important
to retain users. While it may be hard to define good UX, it may be safe to assume that e.g. a sluggish
user interface with illogical placement of elements is likely to steer customers elsewhere. Visual
design should also be modern and kept updated. The more pleasant a product is to use, the more
likely it is that people will use it. We also believe it is important that solutions are easy to integrate
into existing customer systems, for example by standardizing communication interfaces or offer-
ing APIs.
A simple IT architecture and IT infrastructure can support effective use of IT in the business (cf.
the fourth business principle). Focusing on simplifying architecture can trigger reuse of compo-
nents and shared repositories, and thereby reducing time and cost of development. A simple IT
infrastructure can help reduce bottlenecks, or at least make it easier to find them. This also relate
15 London Stock Exchange. 16 Oslo Børs (h).
14
to the fourth IT principle, about the issue of security. A simple IT architecture and IT infrastruc-
ture can be considered easier to secure, simply because it is easier to get a complete overview of
systems and data flows.
The fifth business principle is supported by the fifth and sixth IT principle. Developing solutions
to make market surveillance easier will help OSE excel at this point, and can make it easier to be
compliant. Thorough documentation is useful to make supervisory processes more effective. Doc-
umentation is also useful for getting new employees up to speed faster, in addition to making it
easier to find possible areas of improvement.
6.2 Governance Arrangement
Certain patterns of government arrangements have been proven to surpass others. Which posi-
tions to choose is largely dependent on what sort of business is in question, and what are the main
aspirations of said business. Weill and Ross emphasizes three different aspirations: asset utiliza-
tion, profit and growth. In the interview the CIO mentioned that profit and cost had become in-
creasingly important after the de-monopolization of the stock exchange. In the following chapter
we will present general suggestions for improvement of the OSE governance arrangement as well
as some improvements that could facilitate increasing profits.
6.2.1 Input
In the general category of input, management of IT principles and application needs have proven
universally important. Management of the remaining categories have not proven as significant, as
successful regulation of these are largely dependent on the type of business in question. A general
finding has been that enterprises with high governance performance have been using federal in-
put models for IT principles and business application needs. Conversely, businesses with lower
performances have been applying a duopoly input for IT principles and business application
needs.17
The rationale behind these findings are that the federal input model strikes a balance between the
wants of senior management and the needs of local business unit leaders. It is largely acknowl-
edged that there usually exists a tension in the perception of what should be shared and what
should be locally decided. Sharing enables economies of scale and a holistic approach to IT in the
business, local decisions cater to the needs of more narrowly angled, tailor made solutions for the
business units.
17 Weil and Ross (2004) p. 129.
15
The major drawbacks of the duopoly model for inputs on business application needs are that the
input process comes across as very limited and non-transparent. Parties that are left out of the
input process could have valuable input, but are left out of the loop. A duopoly model might be
better suited for making decisions, which will be discussed in the next chapter.
OSE seemed to have a duopoly approach to input for business application needs. As we mentioned
earlier in the assignment “Input for decisions about business application needs comes from the
director of the relevant business unit and the CIO. Together they make a business case that the
CIO presents in a meeting with the executive committee, which then make a decision.” This is quite
similar to the duopoly as described by Weil and Ross.18 In our interview, the CIO mentioned that
because of its small size, elevating an idea from the floor of the organization to the top, is not really
that difficult. The idea must be “reasonable” and documented to some extent, but it does not have
to go through much bureaucracy before it ends up as a business case in the executive committee.
Thus we suggest that the input model for business application needs at OSE is a mixture of federal
and duopoly. We argue that the small size of the business allows ideas and input to travel informal
paths, making it difficult to identify an exact and consistent flow of input.
6.2.2 Decision
Federal models are not ideal for decision making, however. The federal model emphasizes com-
promise, which is often liable to hurt the effectiveness of the decision outcome. This is often the
result of trying to “keep everyone happy”. This frequently cumulates in a solution which does not
sufficiently satisfy any involved party.19 Every successful business avoided the federal decision
model and appropriated a duopoly approach for critical, high level decisions such as IT principles
and IT investments.
Decisions regarding IT investments are arguably of high strategic value. Therefore, a federal deci-
sion models is ill advised. This could end up undermining the overall goals of the business. Apply-
ing a duopoly model could be a more viable option. This enables joint decision making between
the business leaders and the IT professionals. A business monarchy might be even more appro-
priate. More centralized approaches are usually advantageous in single business unit firms where
cost control and profitability is more important.20 This seems to be more in line with the ambitions
of OSE as cost control and profits have been a key goal for the business.
On the topic of business application needs, the right choice of model largely depends on the busi-
ness. In highly integrated business, such as the Oslo Stock Exchange, business monarchies have
18 Weil and Ross (2004) p. 93-94 19 Ibid p. 131-132. 20 Ibid p. 133–134.
16
proven to be a successful model, because such businesses usually thrive under a centralized deci-
sion making regime.
6.2.3 Profit
Businesses with good profits are recognized as having a centralized approach to governance.
Translated into the language of the government matrix, these organizations have business mon-
archies for IT-principles, high-level IT architecture and IT investment decisions and business or
IT monarchies for infrastructure. This enables standardization of the architecture through busi-
ness decisions, with the IT group as an advising party. They apply federal arrangements for busi-
ness applications needs. 21 This ensures a consistency across business units with firm wide strat-
egies while at the same time recognizing the difference between the business units.
This method of government arrangement puts much of the highly strategical IT decisions in a
business perspective. This requires the business leaders to be IT proficient, and not leave all the
seemingly “too technical decisions” to the IT people. A counsel of IT executives might make the
business leaders better equipped to make informed decisions.
IT principles IT
architecture
IT
infrastructure
B. application
needs
IT investment
I D I D I D I D I D
B. monarchy
IT monarchy
Feudal
Federal
Duopoly
N/A
Table 2: Greyed out fields represent the current government arrangements. Green fields represent suggestions
for improvement.
21 Ibid p. 139 – 140.
17
6.3 Project method
The CIO stated in the interview that OSE had a development method that was tailor made by and
for them. The project and testing chief, who is responsible for their project method, had taken
multiple methodology courses for the major methods and combined elements from all of them
into a universal in-house method. While they did some adjustments in relation to the project size
– like the number of people, meetings and reports – the method was the same for all projects. We
also got the impression the method is under continuous optimization. The CIO also said they strive
to be agile, as this is one of the advantages of being small. However, he was not a fan of going all
in on just one method, as this could lead to too much focus on the method itself. He explained that
OSE once did a project following just Scrum, which turned out catastrophically.
It is hard to recommend any changes to the method OSE use, as it seems to work very well for
them. However, even if they deliver on time and within budget, it may be possible to increase
efficiency and thereby lowering time to market. For example, one could argue OSE should have
practiced more on the Scrum-method. It may take more than one try to complete a Scrum-project
successfully. E.g., it is likely that whoever had the job of Scrum master would need more experi-
ence to get good at it. Being a project manager and being a Scrum master is not the same. As most
projects are managed hierarchically (top-down) by a traditional project manager, the role of the
Scrum master is more of a “primus inter pares”-approach. This may need some getting used to,
especially if the role was taken on by a person with experience in traditional project management.
While we did not investigate OSEs method in detail, it does seem to partly resemble what Špundak
recommends.22 The CIO stated that most projects consist of developing new products for trading.
Once they have finished planning the project, they communicate information about the new prod-
uct and launch date to all customers. It is of essential importance to deliver in time so the traders
do not lose confidence in OSE. For that reason, the requirements have to be fairly clear from the
beginning with a low change rate, which is a characteristic Špundak attributes a traditional ap-
proach.23 The same goes for the characteristics “documentation” and “project plan”; formal docu-
mentation is required, both for the customers and the supervisory authority, and the project plan
must be linear for OSE to finish on time. Their characteristic of “users” and “team members” leans
towards agility; customers are frequently invited for weekend-testing,24 and as they usually de-
velop in-house and are fairly small their teams must also be small. “Project size” and “system crit-
icality” is likely to vary between projects, and could therefore be arguments for OSE to do more
individual adaptations to each project.
22 Špundak (2014). 23 Špundak (2014) p. 945. 24 Oslo Børs (f).
18
When it comes to “organizational support” it is hard to say where OSE fits in. The CIO stated that
they strive to be agile, but that they had failed in their Scrum-project. This may just be a result of
too little experience, but skepticism and willingness could also have played a part. It can be argued
that OSE have embraced an agile methodology: learning about all major methods, mixing elements
from different ones into one and optimizing it based on experience from previous projects. The
method itself, however, can be considered less agile, as they use the same method on all projects
with little individual adaptation. However, this could also be a result of their projects being
roughly the same size with the same properties.
As mentioned above, it is hard to recommend changes to OSEs method. They already seem to have
a well working system in place. Most of their projects are delivered on time and within budget,
which most consider key success criteria. If we were to recommend anything, it would be to go
“all in” when trying out new methods. I.e. embrace them until they are successful with them. By
doing this they will get a better empirical foundation for implementing changes to their “main”
method later. It is important to notice that this will require dedication, time and money. A starting
point for testing out new methods could be with very small teams developing small, non-critical,
in-house only functions. Preferably where the deadline is not of importance.
6.4 DevOps – an alternative approach to projects and project manage-
ment
OSE appears today as a very well-functioning organisation – including their project management
regime. This success, we were made to understand, is partly due to a thorough restructuring of
the organization and project management method, as discussed in chapter 2.1. To avoid a similar
situation to that of ten years ago, and to keep the organization evolving and able to keep up with
demands of the customers, we believe that an alternative approach to project management could
be useful. We believe that DevOps could be a suitable method to provide OSE with improvements
to the software development processes. In the following we will go through how adopting a
DevOps approach could potentially improve OSEs ability to provide continuous deliveries.
DevOps is an approach that tries to deal with inefficiencies in software development processes.
Traditionally, IT developers deliver software to Operation teams, and are no longer involved in
the later stages in the “life cycle” of their development. The operation teams, on the other hand,
are very focused on system stability and hence very conservative in terms of introducing changes
to a system. The result is sometimes a rather rigid approach which is not supporting the dynamics
required for a modern product development. In DevOps, teams are organized across developers,
testers and operation personnel. This gives a more holistic view in the team, and has shown to be
a very efficient way of organizing modern software development and deployment into production.
19
The DevOps approach should be implemented by “aligning” the interest categories of all of these
traditionally different teams within IT.
6.4.1 What is the problem for software development at OSE?
As stated in the interview with the CIO, the IT-department 25 is strictly separated into sub-depart-
ments based on the functionality they perform, creating a strict, silo-based way of managing projects.
This approach is supposed to prevent that the deliverances, when released and put into action does
not contain any major faults, as it would affect the critical system.
To reduce the risk of major software-problems, and to decrease the time spent on making the
systems, we suggest that OSE could adopt the DevOps approach described by Humble and Mole-
sky in their 2011 article.26 They argue that the divide we see in figure 3-2, between the sub-de-
partments “development,” “maintenance/infrastructure” and “project” eventually makes it diffi-
cult to deliver high-quality software. This, they argue, is because the lack of communication and
collaboration between the groups hinders a holistic software development process and product.
To enable a more effective way to produce and maintain software, DevOps maintains that integra-
tion of IT with business is central, as this would enable a business to manage their services not
only from department to department, but all throughout their lifecycle, giving more control and a
better overview over planning, costs and returns. The suggested approach to this, by creating
cross-functional product teams, is quite different from the established organisation of the slightly
rigid OSE. Based on this, we believe the DevOps approach can be suitable for OSE in several dif-
ferent ways/for different reasons.
6.4.2 How OSE can benefit from the approach
First, as stated in the article, one of the major areas of inefficiency in system development is de-
veloping software or features that are eventually hardly used or not used at all. Humble and Mole-
sky argue that this is because there exists a gap between the needs of the organisation and the
system developers. Though OSE appears to us as having little waste, this can always be minimized.
Thus, OSE could benefit from the DevOps-approach in this aspect - saving money, time and re-
sources spent on developing “misunderstood features”. The DevOps devotees argue that this gap
can be closed by establishing a more efficient and flexible process. The approach to this will be
described in more detail below.27
25 See figure 3-2 26 ”Why Enterprises Must Adopt DevOps to Enable Continuous Delivery”, Humble and Molesky (2011) 27 See chapter 6.4.4.
20
Another general problem area that DevOps aims to solve is the lack of getting real feedback on
whether the system being built is actually what was needed/useful, before well into the process
of building it. Though the extensive testing of the critical systems is undeniably necessary for
many of the OSE projects, smaller and more everyday-projects could benefit from an “easier”, au-
tomated procedure, as the DevOps approach offers. Relying heavily on testing cannot always sub-
stitute the value of actually trying out the system in its intended environment.
From an economical point of view, OSE could gain a better impression of the total cost of “the
value provided to the business on a per-service basis”.28 We assume that the funding model
DevOps aims some criticism at is also in use at OSE; given that funding is likely to rely on different
models for the different departments makes gaining a complete impression of the total cost of a
system during its lifecycle difficult. Thus, it could be argued that the OSE would not only benefit
economically from using DevOps, but also gain a more detailed understanding of all of the aspects
of requirements, money and time involved in software-processes.
6.4.3 Adopting DevOps at OSE
To achieve the benefits of DevOps, Humble and Molesky suggests addressing four practices;
- culture
- automation
- sharing
- measurement.
The assumption is that by addressing the practice stated above, OSE could have more frequent,
reliable projects and a more stable production environment.29
Taking the prescribed DevOps features in for a closer look, there are some other benefits that
could fit OSE well. The cultural aspect of the approach seems especially suited to OSE being a small
organisation. A fusion of the departments and would not only be manageable, but also useful. With
cross-functional teams communication beyond their “borders” and gathering around a single goal,
they can gain a real understanding of what is involved in the parts of the process they are not
familiar with. This, in turn could help create services better adapted to communicate with each
other. It could also be argued that in a way, OSE are already using some of the techniques for
sharing, such as for social events.30
28 Humble and Molesky (2011) page 7, paragraph 2 29 Humble and Molesky (2011) 30 The only present use of cloud services was the sharing of the invitation to the Christmas party at OSE
21
In terms of culture, involving operation departments in the development and deployment-pro-
cess, may not be as far away as it would with bigger, more rigid companies. Being a small organi-
zation, OSE should have the flexibility to “mix up” the separated departments, involving develop-
ers to rotate through the operation teams, and introducing representatives from the operation
teams to the planning meetings, showcases and retrospectives of the project teams. In many ways,
the familiarity between the few co-corkers, and the closeness of their workplace and organisation
per se could suggest that they already to some extent are able to call in the necessary people across
departments, despite the separation of disciplines. As such, DevOps could well be a natural im-
provement of the existing culture at OSE.
The practice of automation should also appeal strongly to OSE. Seeing as their systems are critical
and must undergo much time-consuming testing before being employed, the DevOps-goal of en-
suring lower lead times to get rapid feedback trough automation could be valuable. Not to men-
tion that OSE spends a great deal of time and effort on testing – using the deployment pipeline,
some or all of this could be automated. Such automation would free up a lot of resources, enabling
OSE more flexibility and resources to focus elsewhere. Furthermore, the use of a deployment pipe-
line could well be a measure for OSE to secure the releases; passing them through automated tests
could potentially save the OSE valuable time and free up resources to make the process and faster
and smoother.
As for measurements, keeping track of how the business is doing is always valuable. To OSE even
more so, to avoid spending resources and time/money one place when they would have been bet-
ter used elsewhere. Both high level business metrics and key performance indicators at lower
levels are useful – making key numbers available for the staff involved in the software-process
creates motivation, and functions as a reminder of the project as a part of the entire OSE. Humble
and Molesky suggests that any business going for a DevOps approach also should set a time goal,
to reduce the lead time in the process. As delivering software on time is one of the main goals of
OSE deliverances, this time-saving aspect could be a very valuable asset.
The practice of sharing is one that relatively easy could be fit into the existing structure of OSE.
An obvious and easy example is the cross functional teams celebrating the successful releases,
encouraging closer bonds across the departments, and improving the already small and close en-
vironment. In addition, sharing tools and techniques, as well as knowledge, may also be a sensible
way of making sure that the whole IT-department feels involved and shares the responsibility of
developing and running software, as well as strengthening infrastructures and environments.
By implementing the practices above, it is argued that OSE can gain faster feedback on production
readiness for the developers, and that the testers and operators would be able to “self-service”
22
deployments to the right environments on demand.31 The practices mentioned above could also
function as a way to ensure that OSE does not drift back to the way it was organized ten years ago
– keeping it lightweight and “on its toes”. Being satisfied with a certain way of organizing a busi-
ness creates a risk of relaxing and letting it stagnate, leaving it behind its competitors. DevOps
presents continuous delivery as a solution to enable frequent deployments and less production
incidents, keeping in line with the OSE goal of producing “fail proof” software.
As the DevOps approach illustrates, it is of importance to avoid thinking and organizing in “silos”.
By applying continuous delivery OSE may obtain that essential collaboration between IT-teams
are improved; this enhances understanding and reduces time for delivery of functionality. Collab-
oration may help to reach a common goal of successful, stable deployments introduction.
6.4.4 Summary and risk assessment
Though the DevOps approach brings many types of advantages, the special characteristics of OSE,
i.e. vulnerability to security related issues and stability, should also be considered. The risks asso-
ciated with a flexible, but also less predictable DevOps, should be analysed and considered thor-
oughly. One option is to make use of some of the practices and methods, as in a modified and
adapted version – for example by involving cross functional teams and automation. This would
enable OSE to create a more holistic and better software with a higher efficiency. Another obstacle
for OSE to use DevOps is the heavy regulations imposed on the financial industry. This should be
considered but is not taken into the scope of this chapter.
31 Humble and Molesky (2011) page 8, paragraph 5
23
7 Concluding remarks
This paper has provided a short presentation on OSE (chapter 2) and their organizational struc-
ture (chapter 3). Then it presented the key systems and interconnections (chapter 4) and decision
and input rights modelled using the Governance Arrangement Matrix (chapter 5). This chapter
will offer some concluding remarks regarding the assignment and what experiences where made.
First and foremost, this has been an educational process for the group. All of the group members
have a background from the faculty of law. We are somewhat familiar with the concept of IT and
organization, but the concept of practical project management was quite foreign. In retrospect,
we should have started the project management process at an earlier stage of the project. We had
very little knowledge of project management at that stage however, which is slightly paradoxical.
The project has provided some insight into the workings of the IT-department of OSE. One of the
chief concerns of the IT-department is information security. This is understandable, but it has
somewhat hampered the information gathering process as the group could only rely on infor-
mation given through the interview and information already available to the public (Wikipedia,
OSE homepage etc.)
24
References
Oslo Børs (a), The history of Oslo Børs, https://www.oslobors.no/ob_eng/Oslo-Boers/About-Oslo-Bo-
ers/The-history-of-Oslo-Boers [fetched March 8th 2017]
Oslo Børs (b), Facts and figures December 2016, https://www.oslobors.no/ob_eng/Oslo-Boers/Statis-
tics/Facts-and-figures/2016-Facts-and-figures-December-2016 [fetched March 8th 2017]
Oslo Børs (c), Acts and regulations, https://www.oslobors.no/ob_eng/Oslo-Boers/Regulations/Acts-and-
regulations [fetched March 8th 2017]
Oslo Børs (d), Market surveillance, https://www.oslobors.no/ob_eng/Oslo-Boers/Trading/Market-sur-
veillance [fetched March 8th 2017]
Oslo Børs (e), Insider trading / notification requirement for primary insiders, https://www.oslo-
bors.no/ob_eng/Oslo-Boers/Trading/Market-surveillance/Insider-trading [fetched March 8th 2017]
Oslo Børs (f), Technical Service Announcements from Oslo Børs, https://www.oslobors.no/ob_eng/Oslo-
Boers/Trading/Trading-systems/Technical-Service-Announcements [fetched March 22nd 2017]
Oslo Børs (g), About Oslo Børs, https://www.oslobors.no/ob_eng/Oslo-Boers/About-Oslo-Boers [fetched
March 23rd 2017]
Oslo Børs (h), Listing processes, https://www.oslobors.no/ob_eng/Oslo-Boers/Listing/Shares-equity-cer-
tificates-and-rights-to-shares/Oslo-Boers-and-Oslo-Axess/Listing-processes [fetched March 8th 2017]
Oslo Børs VPS, An introduction to the group, http://www.osloborsvps.no/obvps_eng/Oslo-Boers-VPS/Ca-
reer/An-introduction-to-the-group [fetched March 8th 2017]
London Stock Exchange, Listing Process, http://www.londonstockexchange.com/companies-and-advi-
sors/main-market/companies/listing/process.htm [fetched March 23rd 2017]
Purehelp, Oslo Børs ASA regnskap, http://www.purehelp.no/company/account/osloboersasa/983268633
[fetched March 14th 2017]
Špundak, Mixed agile/traditional project management methodology – reality or illusion?, 2014.
Weill, Peter & Ross Jeanne W., IT Governance, 2004.
Lov 29. juni 2007 nr. 74 om regulerte markeder (børsloven)
I
Appendix A – Interview guide
Formålet med intervjuet er å få oversikt over hvordan Oslo Børs håndterer IT-avgjørelser i virk-
somheten. Intervjuet vil bli tatt opp, samtykker du til dette? Samtykket kan trekkes tilbake dersom
du ønsker det.
Innledningsspørsmål
1. Hva er din stilling i bedriften?
2. Kan du fortelle litt om hva den stillingen innebærer?
Historisk perspektiv
3. Kan du beskrive bedriftens IT-situasjon, henholdsvis for tre og ti år siden?
4. Kan vi få se et nåværende organisasjonskart over intern organisering av IT-avde-
lingen – så kan endringer kanskje vises?
Oslo Børs som IT-bedrift
5. Kan du fortelle litt om Oslo Børs som IT-bedrift?
6. Hvilken rolle vil du si at IT spiller for Oslo børs?
7. Kan du gi en overordnet beskrivelse av organisasjonsstrukturen til Oslo Børs?
a. Hvor er IT-avdelingen plassert i hierarkiet?
8. Kan du gi en beskrivelse av IT-avdelingens struktur?
a. Kan du gi oss et overblikk over organisasjonskartet til IT-avdelingen?
b. Hvilke avdelinger finnes?
c. Er noen avdelinger underordnet/overordnet?
d. Kan du gi oss en oversikt over oppgavefordeling for IT-avdelingen?
e. Oversikt over viktige kompetanseområder?
9. Hvordan henger IT-avdelingen sammen med resten av bedriftens struktur?
Organisasjonsstruktur/organisering av informasjonssystemer
10. Hvilke verdier og prinsipper styres børsen etter? (verdier/mål/holdninger)
11. Hvem er det som bestemmer de overordnede prinsippene for bruk av IT?
a. Eksempler på prinsipper kan være «innovasjon», «lavkost», «bruk av de nyeste
teknologiene», «brukeren i fokus» etc.
12. Finnes det noen sammenheng mellom bedriftens generelle styringsmål og IT-sty-
ringsmålene?
13. Hvem er det som tar avgjørelser om IT-arkitektur?
14. Hvem er det som avgjør strategien for IT-infrastruktur?
II
15. Hvem er det som bestemmer hva bedriften trenger av IT-applikasjoner?
16. Hvem er det som tar avgjørelser om IT-investeringer?
Nøkkelsystemer
17. Kan du gi et overordnet bilde av Børsens infrastruktur?
18. Kan du gi oss en oversikt over hoved-/nøkkelsystemene deres?
19. Hva er oppgavene til de forskjellige systemene?
20. Hvordan henger disse systemene sammen med hverandre?
21. Kan du gjøre rede for dataflyten mellom disse systemene?
Eksterne leverandører
22. Benytter dere eksterne leverandører?
23. Når/ i hvilke sammenhenger er det dere benytter dere av eksterne leverandører?
24. Hva slags type forhold har dere til de forskjellige leverandørene?
25. Hvem er det som vedlikeholder IT-systemene deres?
26. Bruker dere skytjenester?
27. Hvilke eksterne kilder for data bruker dere?
28. Hvordan validerer dere denne dataen?
Reguleringer
29. Hvilke rettslige rammer må dere forholde dere til
a. Ved utviklingen av IT-systemene deres?
b. Ved drift og vedlikehold av IT-avdelingen?
c. Er dere underlagt noen spesielle regelverk annet enn de nevnt over?
30. Hvilke typer IT-avtaler har dere?
IT-prosjekter ved børsen
31. Hvordan organiserer dere prosjekter (prosjektmetodikk)?
a. Outsourcing eller in-house
32. Hva slags systemutviklingsmetoder bruker dere?
33. Hvilke typer IT-standarder benyttes til
a. Drift?
b. Utvikling?
Avslutning
34. Er det noe mer du tror du kan fortelle oss for å beskrive den nåværende situasjonen
for IT-administrasjon/avgjørelser hos Oslo Børs?
III
Appendix B – Interview transcription
Interviewer #1: Kristine
Interviewer #2: Andreas
Informant: Kjetil Nysæther, CIO Oslo Stock Exchange
Da starter jeg med noen innledningsspørsmål. Kan du fortelle meg hva din stilling i bedriften er?
Ja, jeg er IT-direktør.
Kan du fortelle litt om hva den stillingen innebærer?
Den innebærer jo at jeg leder hele IT-enheten som består av en utviklingsenhet en driftsenhet og en pro-
sjekt-enhet, så jeg har da det overordnete ansvaret for hele IT ved Oslo børs og rapportere til børsdirektør
og sitter i børsens ledergruppe.
Så vil vi gjerne, hvis du kan gi oss et lite historisk perspektiv, kan du beskrive bedriftens IT-situasjon,
henholdsvis for tre og ti år siden?
Ja, det er jo egentlig interessant, for vi har jo hatt en fin reise – for ti år siden så hadde vi en situasjon sånn
organisatorisk så var den egentlig veldig lik men, systemmessig så hadde vi da et veldig komplekst
systemlandskap med mange systemer som var bygget på ulike typer teknologier. Vi kom jo da fra en histo-
rie hvor børsen hadde vært en stiftelse, så gikk vi fra å være en stiftelse til å bli et AS, men fortsatte være
monopolbedrift så gikk vi fra å være monopol til å bli konkurranseutsatt, da stiller en litt andre krav til
hvordan man strukturerer og jobber fra. Mer krav til lønnsomhet og kostnadskontroll. Så for ti år siden
hadde vi veldig mye forskjellige og komplekse systemer, bygd på ulike teknologier – mye best of breed-
tankegang, mye dyr innkjøpt software. Så tok vi og gjorde en del strategiske beslutninger om at vi skulle
standardiserer på standardsystemer og teknologier, så vi valgte å kjøre SQL-server som database, vi valgte
Windows som operativsystem og Java som utviklingsmiljø. Så har vi ryddet opp og sanert og kvittet oss
med mye gamle og dyre systemer og teknologier. Og redusert kostnadene og også dratt ned antall hoder
da. Så vi har redusert antall årsverk fra 43 ned til 24.
Det er ganske drastisk.
I løpet av den perioden ja, og det har vært som en følge av de tingene vi har gjort på teknologi og systemsi-
den. Outsourcet en del tungt webmiljø som vi prøvde å få alt internt, og så lagt ned et stort og tungt data-
varesystem. Så vi har gjort mye grep for å effektivisere bedriften.
Ja, det er veldig interessant for oss. Og så lurte vi på, det kan vi eventuelt komme tilbake til - om du
kunne skissere et nåværende organisasjonskart over intern organisering av IT-avdelingen, bare for å
si kanskje litt om hvordan det har endret seg?
Ja, altså, selve organiseringen av IT-avdelingen har ikke endret seg vesentlig i løpet av den perioden. Vi
har en tradisjonell organisasjon hvor vi har en utviklingsavdeling, IT-utvikling, vi har en avdeling for drift
og infrastruktur, hvor det også er et driftssenter en helpdesk som er bemannet fra 7 om morgenen til 8 om
kvelden, vi kjører jo drift hver dag. Børsen er jo en produksjonsbedrift. Så har vi en prosjektavdeling som
IV
egentlig er et prosjekter og test, der har vi et prosjektkontor og en testavdeling. Så det er egentlig tre av-
delinger under meg. I tillegg så har vi to kall det litt sånn stabsfunksjoner, det er en IT-arkitekt-rolle som
rapporterer til meg og som sitter i IT-ledergruppen og så har vi en avdeling som på en måte er en mann
som har ansvaret for de tjenestene vi har satt ut til London Stock Exchange som er handelssystemene. Så
han sitter da og har ansvaret for å følge opp den utkontrakteringsavtalen vi har med London Stock Ex-
change.
Hva slags bakgrunn har han?
Han er en, han er vel en gammel utvikler, men han har vel jobbet mye med oppfølging og avtaler i Norges
Bank også.
Så han har en del juridisk kompetanse også kanskje?
Nei, han har ikke juridisk kompetanse. Vi har en juridisk avdeling på børsen som vi…
…det er det tekniske i den avtalen som blir fulgt opp av…
Ja, det tekniske i den avtalen blir fulgt opp av oss. Altså, jeg eier avtalen, men jeg har støtte fra juridisk her
på huset i forhold til å gjøre endringer og revisjoner av den avtalen så har jeg alltid en jurist med på det
arbeidet, fordi den avtalen er jo skrevet av jurister på engelsk side og det, det er ikke alt der som er like
lettlest, for å si det sånn.
Nei, det skjønner jeg godt.
Så vil vi gjerne spørre litt om Oslo børs som bedrift og som IT-bedrift.
Ja.
Kan du fortelle litt om Oslo børs som IT-bedrift?
Som IT-bedrift, ja altså det… IT det er jo en helt sentral komponent i drift av børsen, så hvis IT-systemene
stopper så stopper jo handelen og da må vi stenge markedet og. Så IT-er jo egentlig livslinjen til Oslo børs,
og det gjør jo at det er spennende sted å jobbe, når man jobber med IT-fordi It-har høyt fokus både utvik-
ling, drift også det med IT-sikkerhet som er en meget viktig del av det vi driver med. Man jobber veldig
tett med fagmiljøene, altså de ulike forretnings og fagmiljøene på huset så det er en sånn veldig tett inter-
aksjon mellom IT- og forretningsområdene som gjør at det er veldig spennende å jobbe her. Ellers så er
det jo preget av at man lever med de systemene man utvikler, så hvis man har vært med å utvikle noe så
har man også ansvaret for at det skal fungere hver dag i produksjon, og skjer det noe på kveldstid så har
man ansvaret for å stille opp og fikse det. Det er liksom ikke noe alternativ å vente til neste dag hvis in-
deksberegningen feiler, da må man bare fikse det der og da for det skal være riktig til neste morgen. Så det
er jo noe av det som gjør det morsomt å være her, at det er en sånn puls og en nerve knytta til IT- og hvis
et av systemene våre går ned i eller rett før åpningstiden, Gud forby, så må man bra hive seg rundt og få
det opp igjen så fort som mulig, men det er en sånn puls og nerve som gjør at det er litt mer gøy her enn i
et forsikringsselskap for eksempel.
Føler du eierskap til systemene selv?
V
I veldig stor grad, ikke sant det er jo det som gjør det gøy å være her i forhold til det å være en konsulent,
du får et veldig sterkt eierskap til det du lager og det du leverer og du jobber jo ved siden av de som bru-
ker systemene dine, og du har en veldig sterk «i samme båt»-følelse her på huset, og det er jo morsomt når
vi gjør prosjekter, så staffes de opp med ressurser fra hele huset og så jobber man i felleskap for å få på
plass nye releaser og handelssystemer eller… det er ja,
Riktig.
Yes, så kan vi kanskje hoppe over neste, som var hvilken rolle vil du si at IT spiller for Oslo Børs, siden
du svarte litt på det allerede, så kan du kanskje heller si noe overordnet om organisasjonsstrukturen
til Oslo Børs.
Struktur…
Du sa kanskje litt om det i stad…
Spørs kanskje litt i hva du legger i…
Sånn som hierarki på en måte.
Det er veldig lite hierarkisk, det er en ganske flat og uformell organisasjon, hvor det er veldig mye jobbing
på tvers av de ulike avdelingene og de ulike forretningsområdene. Ellers, det som særpreger Oslo børs er
at det er korte og raske beslutningsveier, altså det er, fra man har en god tide til man har et businesscase,
det er, man kan raskt få gjennomslag for ting, få satt i gang nye ting hvis det er fornuftig og godt begrun-
net, det er noe av det jeg liker med Oslo børs – det er veldig lite byråkratisk.
Hva kommer det av at det er så kort vei til å få gjennomført ting tror du?
Ja, altså det er jo en liten bedrift, vi er jo bare en 85–86 ansatte, og det er jo noe av fordelen ved å være li-
ten bedrift, sittende i et lite hus – man jobber tett på hverandre og det blir raske og effektive prosesser.
Det er jo noe av det vi har jobbet med på IT- og på huset ellers er jo å ha effektive og optimale prosesser på
alt det vi driver med.
Ja, skal vi se, fortsetter litt på en beskrivelse av IT-avdelingens struktur. Kan du si noe om det?
Altså, strukturen, jeg var jo innom organisasjonskartet, og strukturen følger jo litt det – vi har jo som sagt
en utviklingsavdeling som er ansvarlig for nyutvikling og forvaltning av IT-system som er internt utviklet,
vi har en ganske stor portefølje av internt utviklede systemer. Handelssystemet er jo om sagt satt ut sa de
driftes av London Stock Exchange og utvikles av et selskap som heter Millenium, som holder til ned på Sri
Lanka. Vi har en drifts og infrastrukturavdeling, så de er ansvarlig for alt vi har av infrastruktur. Vi kjører
jo drift på to siter, for å ha full redundans, så hvis noe går ned et sted så failer det over og går videre på
den andre siten, så det er jo noe av det vi på en måte har krav på oss til – det er jo å ha gode kontinuitets-
miljøer, så hvis noe går ned så skal det ikke merkes ut av huset. Veldig mye av det vi driver med er jo pro-
sjekter. Vi jobber veldig mye i prosjekt, så til enhver tid har vi sikkert et par tre prosjekter gående, så noe
av det større vi driver med er jo når det kommer en ny versjon av handelssystemet, som vi er nødt til å
gjøre tilpasninger til, for da må man jo tilpasse de interne systemene og meglerne må gjøre tilpasninger på
sine systemer, så det er ganske stort apparat som settes i sving da, og så veldig mye testing i helgene, er
det andre ting du tenker på når du sier struktur?
VI
Ja, det er jo litt sånn hvilke avdelinger finnes, hvordan oppgavefordelingen er i IT-avdelingen, eller
hvilke kompetanseområder som finnes, for eksempel.
ja, det er jo – i IT-prosjektene så er det jo IT-utviklerne som jobber, og så test er jo også en veldig viktig
funksjon, for alt det vi bruker må jo testes før det settes ut i funksjon, vi har jo veldig lav toleranse for feil,
så det, testing er veldig viktig. Vi har testressurser som jobber på IT, men når vi kjører prosjekter så hen-
ter vi ressurser fra huset ellers, fra forretnings og fagområdene, som da er med å tester det som blir levert,
kjører akseptansetestene av alle leveransene, og det er jo, testing utrolig viktig, for vi kan ikke feil i pro-
duksjonen, så tekstfunksjonen er noe av det mer sentrale vi har. Det blir en sånn tverrfaglig disiplin egent-
lig hvor det både er IT-folk men også folk fra de ulike områdene som sitter og jobber sammen.
Ja, kan du si noe om hvordan IT-avdelingen henger sammen med resten av bedriftens struktur?
Ja, struktur –
…eller organisering
Ja, jeg rapporterer jo til børsdirektøren så sånn sett er jo IT- sidestilt med forretningsområdene…
Det er kanskje det vi er mest interessert i.
…for noen steder så er jo IT underlagt stab eller finans og sånn sett litt gjemt bort, så jeg vil jo si at måten
man har organisert det på her på huset er jo mer riktig i forhold til IT sin viktighet for forretningen.
Ja, da tror jeg vi går over på neste punkt, om litt sånn organisasjonsstruktur, organisering av IT-syste-
mer i Oslo Børs, og vi er litt interessert i hvilke verdier og prinsipper børsen styres etter – altså, mål
verdier og holdninger som børsen som bedrift.
Oj, det var litt sånn vanskelig spørsmål
Ja, det er lite håndfast, men ja man… type veldig abstrakte verdier.
Ja, jeg har jo gjort litt undersøkelse, så for eksempel så vet jeg at dere har en del etiske retningslinjer
og sånn som dere må forholde dere til som er styrende for hvordan bedriften drives da.
Ja, ja det har vi. Vi har veldig mye – vi har etiske retningslinjer og vi har veldig mye mål, altså, vi har kvali-
tetsmål som er veldig viktig for hvordan vi jobber på IT, for det sier jo noe om hva systemene våre skal
levere på. Så det er oppetid, feiltoleranse, sånne type ting. Ellers så har vi veldig mye retningslinjer rundt
at vi ikke skal handle aksjer eller verdipapirer notert på Oslo børs, vi har sånne typer retningslinjer.
Men da er det for eksempel, i deres tilfelle da – så er dere mer styrt av robusthet og sikkerhet enn å
pushe ut applikasjoner og funksjoner så for som mulig for det er jo avhengig av at alt fungerer veldig
ja, det vi jo er veldig styrt på er jo at vi må levere, altså, alle beregninger må være korrekte – folk sitter jo
og handler på grunnlag av produkter eller informasjon som vi sender ut, så det må være 100% riktig det vi
sender ut. Og så må det være robust og som du sier, alltid tilgjengelig, det kan ikke være sånn at indeksene
faller ned en halvtime på slutten av dagen
nei
så vi på IT er jo da veldig styrt av de kvalitetsmålene som gjelder for oss og alle systemene våre er jo kate-
gorisert slik at noen systemer er jo kritiske – det er handelssystemer, og så har du viktige systemer og
VII
standarder, og hver kategori angir hvor høy oppetidskravene er, om det er 99.95, eller om det er 99.9 hvor
raskt man skal ha systemet oppe igjen ved en feil, hvor lenge det kan være utilgjengelig ved en katastrofe-
situasjon, sånne ting, det angis jo i graderingen og kategoriseringen av systemene. Så systemene våre er jo
kategorisert i henhold til det.
vi går litt videre – vi prøver oss igjen på litt sånn overordnede prinsipper – hvem er det som bestem-
mer de overordnede prinsippene for bruk av IT, kan du si noe om det?
de overordnede prinsippene for bruk av IT?
altså, de overordnede prinsippene kan jo være hva dere styres etter, om dere skal holde dere til lav-
kostnad,
kvalitetsmålene, om det er IT-avdelingen som bestemmer det, eller er det ledelsen som altså
nei, det er jo disse – forretningssiden som angir hvor kritiske systemene er for deres daglige virke, men
det er jo ledergruppen som beslutter de målene og normene vi skal jobbe etter.
og ledergruppen, da sikter du til toppledelse eller?
toppledelse ja
men er det en sammensatt gruppe av
der sitter jo børsdirektør, jeg sitter der, så er det leder for juridisk, for
ja, riktig, så alle er representert med andre ord
så det det er jo børsens øverste ledelse. Så har vi også, vi har jo veldig mye kvalitetsdokumentasjon, og
mye er jo godkjent av styret, overordna instrukser og policyer, så har vi en del interninstrukser som er
godkjent på nivået under, så vi har et hierarki av kvalitetsdokumentasjon som på en måte styrer det aller
aller meste av det vi driver med, vi har instruks for IKT-sikkerhet, vi har kontraktering av tjenester, vi har
instrukser for informasjonssikkerhet, så det er jo et hierarki av dokumentasjoner som angir hvordan vi
skal agere nærmest i enhver situasjon. Og avhengig litt av nivået så er det godkjent enten i styret, i leder-
gruppen eller på seksjonsledernivå da.
For det vi vel lurte litt på var vel om det finnes noen generell, eller, sammenheng mellom bedriftens
generelle styringsmål og IT-styringsmålene, om de styres etter de samme
ja, eller om det er sånn at toppledelsen, eller forretningsledelsen bestemmer et sett med, liksom prin-
sipper og holdninger, eller ønskede holdninger blant sine ansatte og så går IT-prinsippene liksom ut
fra det
Nei nei, det er jo et felles sett av, det er jo et felles sett av kvalitetsdokumentasjon der som på en måte som
styre alt dette her. I tillegg til det så har vi også den IKT-forskriften som vi må forholde oss til vi er jo un-
derlagt tilsyn av finanstilsynet, så finanstilsynet kommer og har tilsyn både med Oslo børs som helhet,
men så har de også spesielle IT-tilsyn, hvor de kommer og ser på IT-enheten spesielt. Så dette henger vel-
dig greit sammen. Jeg føler liksom ikke at det er noen mismatch mellom hvordan vi på IT tenker og agerer
og hvordan forretningssiden…
nei
VIII
dette er veldig alignet.
ja, det er kanskje det vi er mest ute etter, om det er noen spenningsforhold eller om
Nei, egentlig ikke, dette er veldig sånn… samkjørt
Det vil jo tilsi at dere er en veldig god IT-bedrift da. Ifølge vårt pensum i hvert fall!
ja, jeg… altså, vi hadde en ja… vi har jo fått litt skryt for det vi driver med. Tror vi har en bra IT-organisa-
sjon her
med mer, høres sånn ut – det stemmer med pensumteorien!
ja det er jo hyggelig å høre, jeg har ikke lest pensum men vi har jo noen års erfaring og på en måte, dette er
jo et system som har blitt tuna og skrudd til over mange mange år og vi har jo folk som har vært her lenge
og har mye erfaring, så vi har en velfungerende enhet på IT
tenkte bare å ta et par kjappe, litt mer spesifikke spørsmål om hvem som tar hvilke avgjørelser. Hvem
er det som tar avgjørelser om IT- arkitektur for eksempel?
Det er IT-arkitekten som har det øverste faglige ansvaret der
dere har én sjefsarkitekt?
vi har én sjefsarkitekt og han rapporterer til meg
men av avgjørelser om IT-arkitektur er det
Gjøres i IT-gruppa
okei, så det er IT-avdelingen isolert sett som tar den avgjørelsen?
ja
Og strategi for IT-infrastruktur, er det, hvem tar det?
Vi har en IT-strategi som omhandler alt det vi driver med og infrastruktur inkludert, så det gjøres… det er
avdelingsleder for drift og infrastruktur som hard et øverste ansvaret for infrastrukturen da. Så han kom-
mer jo da med innstillinger om hva han ønsker å gjøre, og det er veldig sjeldent at jeg går på tvers av hans
faglige råd, men når det gjelder, hvis man på en måte skal investere I ny infrastruktur så må jo det god-
kjennes i ledergruppen, det er jo… da løftes det opp der med innstilling og et businesscase og så blir det
godkjent der. Vi har jo gjort veldig mye på infrastrukturområdet de siste årene, vi har faktisk skiftet ut
hele infrastrukturen vår nå i løpet av tre år, så vi har gjort et kjempeløft på infrastrukturområdet, det er,
der har vi jo fått mye bedre oppetid og mye lavere kostnader så der har det vært veldig mye gøy å drive
med.
hvor kom initiativet til å skifte ut den infrastrukturen fra?
Den kom fra drift, fra infrastrukturenheten vår
det er de som ser behovene for
ja, altså behovene, de er jo nærmest, ikke sant, de sitter og drifter og forvalter serverne og nettverket, lag-
ringsenhetene våre, så de sitter jo nærmest og ser på en måte hva slags behov vi har, ser hva de bruker tid
IX
på så de vi har gjort er at vi har investert i noe som heter konvergert infrastruktur, som er en sånn, man
får nettverk- og lagringsservere i én enhet, med ett administrasjonsgrensesnitt til, og nå driver vi å skifter
ut alt av kjernenett og sikkerhetsinfrastruktur. Så vil si at det er veldig mye å hente i å investere i infra-
struktur, man får faktisk, altså, prisene på per enhet har jo falt veldig de senere årene. Man får jo lavere
innkjøpskost og man får lavere forvaltningskost over tid. Og mer hensiktsmessige verktøy for å vedlike-
holde, så det har vært mye å hente i å investere i det. Men sånne investeringsbeslutninger blir tatt i leder-
gruppa. Så da skriver jeg og den som er avdelingsleder for drift og infrastruktur skriver da en innstilling
med hva vi ønsker å gjøre med investeringskost, forvaltningskost, besparelser, businesscase knyttet til
kostnader til funksjonalitet, og som regel får man gjennomslag for det i ledergruppen. Så, med mindre det
er helt opplagte feil i det vi leverer, så…
Så vil det si at det er dere som bestemmer hva bedriften trenger av IT-applikasjoner?
Nei, av applikasjoner, er det ikke vi som bestemmer nei, fordi, da er det jo forretningssiden som er sty-
rende i forhold til hva de har behov for av applikasjoner.
riktig. Men avgjørelsene om hvilke applikasjoner som skal skaffes og sånn det tas da i IT-gruppa?
nei, det er i ledergruppen, fordi vi har alle systemer, vi kaller det systemer vi da. Alle systemer har en sys-
temeier på forretningssiden, som på en måte… hvis man skal gjøre noe vesentlige endringer på det syste-
met så er det systemeier og IT i fellesskap som på en måte lager en innstiling i forhold til hva man ønsker å
gjøre
Ja, og systemeier kan være i alle forskjellige avdelinger, eller i forskjellige avdelingen, på en måte?
ja, gjerne innenfor et forretningsområde, førstehåndsmarkedet, annenhåndsmarkedet markedsdata, så
det er jo ikke sånn at IT på egenhånd finner at vi må ha et nytt system
nei
eller at vi må gjøre noe med det systemet, dette er jo et samarbeid med en systemeier. Alle systemer har jo
en eier, altså systemeier er jo på en måte sponsoren, som på en måte sier at dette må vi gjøre, dette er vik-
tig for oss på forretningen, hvis vi gjør dette her kan vi effektivisere, kan vi bruke mindre tid i linjen, vi kan
eventuelt realisere nye produkter. Så det er jo det som gjør det gøy å jobbe med IT her man jobber tett på
forretningssiden og alt er veldig forankret i forretning, så det er ikke sånn at IT sitter på roteloftet og kok-
kelerer på egenhånd. Sånn gjør vi ikke.
Så IT, avgjørelser om IT-investeringer det tas i…
ledergruppen, ja
da går vi litt over på, vil gjerne stille deg noen spørsmål om nøkkelsystemer hvis du kan svare da. Må
bare svare på det du vil
Ja
kan du gi et overordnet bilde av infrastruktur når det gjelder systemer?
X
ja altså, handelssystemet er jo. Kjernesystemet vårt er jo handelssystemet, for vi har to handelssystem, et
for aksjer og renter og et for derivater de driftes av London Stock Exchange. Så de står da og kjører i data-
haller i London-området, går på to haller der. Mellom oss og London så har vi dedikerte nettverk som vi
kaller back bone network, som da er tre separate linjer som er dedikert til kommunikasjonen mellom oss
og handelssystemene i London.
de er separate fordi de skal være redundante liksom?
Ja. Og så på vår side så har vi det vi kaller downstream systems eller nedstrømssystemer, det er en type
indeksberegninger, indeksen er kanskje det mest kjente merket ved en børs, ikke sant – det er jo det det
ofte refereres til, om indeksene går opp eller ned, og de beregnes her hos oss, på grunnlag av data som
kommer fra handelssystemene i London. Og så feeder vi også det ferdige resultatet inn i handelssystemet
igjen. Så har vi type nyhetsmeldinger hvor alle selskapene sender ut melding om nye kontrakter eller re-
sultatvarsler eller sånt noe, det har vi et system for, nyhetstjenesten, vi har masse markedsdataprodukter,
vi har databaser, vi har eh, både markedsdata og også analysebaser. Og alle sånne systemer er driftet og
forvaltet og utviklet in-house. Så det er litt sånn veldig grovt overordnet hvordan det ser ut, så har vi en
meldingsbuss, vi har en meldingsbussorientert arkitektur, så alle systemene kommuniserer via en mel-
dingsbuss. De abonnerer på meldinger og publiserer meldinger på den bussen. Så det er sånn hub and
spoke type arkitektur.
er det noen systemer som er ekskludert fra den meldingsbussen?
Nei, det er ikke noen som er ekskludert, men det er jo på en måte bare de som har, som er realtidsorien-
terte som
som kommuniserer på den
Ja, så du kan si at Børsen er veldig sånn realtidsorientert i åpningstiden, fra børsen åpner til den stenger
så er alt i realtid og du skal ha så lite forsinkelser som overhodet mulig på alt som går av meldinger. Med
en gang børsen er stengt så går vi over i en sånn batch ettermiddag, kveldsløp hvor man driver og knar
alle dataene man har fått inn, beregner grunnlag for neste dag, referansedata, disse papirene skal kunne
handles på neste morgen, dette er startkursen, så mange aksjer er til notering. Så lager man også indeks-
verdier, grunnlag for det til neste dag. Så det er et kveldsløp og så er det på’n igjen neste morgen. Og slik
går no dagan. Så alt dette her må jo spille klokkereint hele tiden
du har allerede sagt litt om hvordan systemene henger sammen, er det noe mer du kan si om datafly-
ten mellom systemene, eller har du stort sett…
Nei, har jo egentlig sagt at det er jo, som sagt denne meldingsbussen vår som er nervetråden i realtidsyste-
mene våre, ellers så pusher vi jo ut markedsdataprodukter via FTP litt sånn gammeldags kanskje, men det
er jo også sånn mottakerne vil at det skal være så…
Ja, jeg lurer på om vi kan gå videre til eksterne aktører jeg. Vi… Benytter dere dere av eksterne aktø-
rer?
i veldig liten grad, fordi, vi, som sagt vi er jo underlagt IKT-forskriften og vi er konsesjonsbelagtvirksom-
het, så det er jo visse forankringer på hva vi egentlig kan sette ut. Vi har fått lov til å sette ut handelssyste-
met til London Stock Exchange, eller så er det veldig liten grad eksterne aktører, vi har som sagt kontroll
XI
på datahallen og infrastruktur selv, vi bruker noe konsulenter til utvikling hvis vi har topper, men også det
i veldig liten grad, så det er i stor grad selvforsynt. Veldig lite lavkostland i den tredje verden for eksempel,
og skybaserte ting, det benytter vi oss ikke av.
er det en sikkerhetsavgjørelse, eller er det en
ja, det er delvis en sikkerhetsavgjørelse, men det er også det på en måte å vite hvor dataene dine er til en-
hver tid ha kontroll på det
det er kanskje også en type stakeholder-avgjørelse, for man føler mer eierskap til systemene
ja det er, men så er det også litt det som forskrifter og regler og lover sier at vi skal ha
ja, riktig
er det regulert av sikkerhetsloven?
Regulert av sikkerhetsloven, det tror jeg ikke vi er, nei
i hvilke sammenhenger er det dere benytter eksterne leverandører, det blir jo kanskje hovedsakelig for
ja det blir jo bare i den ene sammenhengen da
men det er klart, vi kjøper jo inn infrastruktur fra eksterne leverandører, vi bygger det jo ikke selv
så det, har dere noe forskjellige forhold til forskjellige leverandører, for eksempel, dere har ett forhold
til London Stock Exchange og så har dere kanskje et forhold til leverandør av Microsoft, eller sånne
type ting?
Ja, altså vi har et strategisk partnerskap med London Stock Exchange, det er både et strategisk element og
et teknologielement i den avtalen som vi har med London. Ellers så har jeg egentlig som prinsipp å være
notorisk utro ovenfor alle leverandører fordi man får gode priser når man bytter, eller så er det som for-
hold flest, det surner litt sånn over tid, så, jeg ønsker å hele tiden være i en posisjon hvor vi kan ha flere
alternative tilbydere av de tingene vi skal ha, hvor vi ikke er i en posisjon hvor vi på en måte har blitt
boxed in av én leverandør og sitter litt sånn fast.
vedlikeholder dere infrastruktur og alt sammen selv også?
vi har jo partnere, så hvis det ryker noen kort i en hardware-boks, så kommer det folk og hjelper oss med
å bytte det og det har vi jo supportavtaler som gjør at da kommer de på minutter, maks timer ikke sant
ja, riktig, riktig
Men alt dere, dere vedlikeholder systemene selv?
ja
bruker der skytjenester?
nei, til julebordinnkallingen – julebordinvitasjonen tror jeg ligger i skyen, emn ellers så gjør vi det i veldig
liten grad.
hvor stor kontroll har dere på hva ansatte har lov til å installere på sine pc-er?
XII
de har ikke lov til å installere noe som helst på sine pc-er. Vi kjører veldig sterk endepunktkontroll og det
er ikke noe bring your own greier hit.
så det er ikke noen ansatte som sitter med Dropbox på maskina si liksom
ikke noe Dropbox og sånt noe nei. It-sikkerhet er veldig viktig her hos oss og det er jo på en måte via klien-
ten, det er den angrepssektoren som er mest benyttet, så vi satser veldig hardt på å ha kontroll på klienten
Ja, dere, børsen driver jo mye med data – kan du si noe om hva slags eksterne datakilder dere bruker?
de eksterne datakildene er jo primært handelssystemet, det er jo der meglerne legger inn ordre og trades
og så er det nyhetsmeldinger. Men dette foregår jo veldig i sånne lukkede nett da, nyhetsmeldinger kan
komme via Hugin eller Cision, ellers så er det… det er veldig lite eksterne datakilder hvis det er det du ten-
ker på.
okei, så da trenger dere ikke gjøre så mye for å validere den dataen?
nei for dette går jo på predefinerte protokoller, alle handelssystemtrafikk kommer på en protokoll, men
det blir jo verifisert av våre adaptere, men dette er jo sånn veldig… som sagt det går på lukkede nett, og
det er ikke noe eksterne ukjente datakilder vi har å forholde oss til
jeg lurer på – vi har jo vært litt inne på reguleringer tidligere, er det noe du har lyst til å føye til om
hvilke rettslige rammer dere må forholde dere til?
ja dette er jo sånn som – det er en jobb i seg selv å holde styr på alt dette her, så vi har heldigvis en kvalitet
og compliance-avdeling her på huset som støtter oss veldig i dette arbeidet, ikke sant, nå skjer det veldig
mye i personvernområdet. Så vi har jo har jo en kvalitet og compliance-sjef og han har fått heldigvis en
ressurs til i sin avdeling, som støtter oss veldig i forhold til hva vi må ha på plass for å være compliant i
forhold til lover og regler. Så det er veldig god støtte å ha i den kvalitet og compliance-avdelingen.
er compliance-enheten en kombinasjon av jurister og teknologer og diverse annet da, eller er det kun
jurister?
nei, jeg vet ikke om de kun er jurister, men vi har noe som heter kvalitet og sikkerhetsforum også. Det er
et forum som møtes månedlig for å diskutere den typen problemstillinger da. Så det jobbes mye tverrfag-
lig med kvalitet og compliance på huset her.
for det er jo veldig relatert. Det er jo vanskelig for jurister å sette seg inn i hva som skal til for at en IT-
avdeling er compliant, tenker jeg.
Ja, men vi har jo som sagt, det syns jeg fungerer veldig bra fordi vi jobber veldig tett med kvalitet og com-
pliance-enheten her. Så de er veldig behjelpelige når vi skal revidere kvalitetsdokumentasjon, eller det er
noen interne instrukser eller retningslinjer som må tilpasses fordi det skjer endringer i lovverket, så får vi
god hjelp og støtte der. Det er nyttig fordi, jeg har ikke nubbsjangs til å sitte og holde track på alt det som
skjer av endringer på lov og reguleringssiden, det er jo et kjempeområde.
Skal vi si noe om IT-prosjekter, eller skal vi hoppe over det
ja, du har vel vært gjennom det meste, alt er internt av prosjekter dere gjennomfører og…
XIII
Ja, vi har en prosjektmetodikk som er tilpasset in-house, vi er litt sånn, vi plukker litt det vi liker fra de
ulike metodikkene og skalerer det ned og tilpasser det egentlig vår størrelse og vår måte å jobbe på. Så
hun som leder prosjekt og test-avdelingen, hun er også ansvarlig for prosjektmetodikken, hun har liksom
gått litt SCRUM-kurs og litt Prince2 og litt PMP og har kontroll på det som fins av sånne store prosjektme-
todikker der ute og så plukker vi de elementene vi liker og så har vi en egentlig en veldig god prosjektme-
todikk som passer veldig bra for vår størrelse, veldig bra for måten vi jobber med.
Har dere noen klare retningslinjer for hvilke metodikker dere bruker på små prosjekter i forhold til
store for eksempel?
nei, vi bruker den samme metodikken hele veien, vi har én metodikk, og den passer faktisk. Det er klart, er
det et veldig lite prosjekt så kan det hende at styringsgruppen ikke er så stor, vi har kanskje ikke så ofte
møter, man drar litt ned på rapportering, man tilpasser det jo, men det er samme metodikken og det er jo
de samme tingene vi gjør hele tiden
heller den metodikken i noen spesiell, altså når det gjelder systemutvikling, er det mer agilt eller er
det…
vi prøver å være smidig, altså det er jo det fordelen med å være liten er at du kan være smidig, men det er
jo ikke scrum vi kjører, vi har jo forsøkt å kjøre et prosjekt i henhold til scrum-metodikken, men det ble jo
katastrofe. Jeg tror jo at hvis man blir veldig opphengt i en bestemt metodikk så blir det på en måte vikti-
gere enn det du faktisk skal levere, er i hvert fall det jeg har sett - folk har en tendens til å bi mer katolske
enn paven hvis de tror at noe er veien til frelse. Så det… Det er jo pragmatikk som er rettesnoren vår, at vi
skal levere noe, at det skal funke og at veien dit må være så hensiktsmessig og smidig som overhodet mu-
lig. Kan liksom ikke rote oss bort i kjempesvære metodikker og prøve å gjøre det etter en eller annen lære-
bok.
er dere veldig strikte på leveringsdatoer og sånt eller
ja, det er vi jo. Datoer blir jo kommunisert eksternt, vi kommuniserer til markedet at den datoen så skal vi
gå live med det og det og det, og da er det veldig viktig for oss at vi faktisk når de datoen. Datoer er veldig
viktige for oss så det, stort sett så holder vi de datoene vi lover.
og det er det samme med intern produksjon, hvis det ikke skal ut på en måte
ja, ja, selvfølgelig. Ofte er det jo ting som skal ut. Ofte er det et nytt produkt en handlebar indeks eller et
eller annet, og da må det jo ut og da må det leveres til den datoen. Så leveransepresisjon er veldig viktig
for oss. Det å faktisk levere akkurat det vi skal til den datoen og til den prisen vi har satt, det
jeg tror har fått spurt om det meste da, så da tror jeg vi bare avslutter med et litt åpent spørsmål om
det er noe mer du tror du kan fortelle oss for å beskrive situasjonen i IT-
er det noe du føler vi har glemt å spørre om eller
Nei, vi har jo vært innom, nå vet jeg ikke riktig hva på en måte dere skal bruke dette til, men vi har vært
innom det meste på et overordnet nivå, så jeg tror dere har fått et relativt greit bilde av egentlig hvordan
Oslo børs It driver og går her. Vi er jo 24 stykker fordelt på de avdelingene vi har nevnt, så det er jo en li-
ten og effektiv avdeling. Leverer relativt mye med få ressurser.
XIV
Ja, da tror jeg vi sier tusen takk
bare hyggelig!
XV
Appendix C – Project charter
Project statement of work
The purpose of this project is to produce two deliverables whose contents are defined in the “Pro-
ject work for INF5890 (spring 2017)” document. In short this involves mapping out the aspects of
IT governance and organization in use at Oslo Stock Exchange the second deliverable expands
upon the first deliverable by identifying areas for improvement and suggestions for improve-
ments.
Authorizing the project
The project has been requested and (sort of) authorized by the Department of informatics at the
University of Oslo.
Project scope
To complete the first deliverable (15–20 pages) we need to:
1. Find a suitable business for our case
2. Create a gantt chart
3. Develop an interview guide for the IT director
4. Conduct an interview with the IT director (or person with similar experience)
5. Gather relevant information and documents related to the business
6. Deliver deliverable 1
7. Present deliverable 1
To complete the second deliverable (no more than 30 pages) we need to:
1. Distribute tasks
2. Find areas of improvement
3. Research the curriculum on IT governance and IT management
4. Propose solutions to the given areas
5. Deliver deliverable
6. Present deliverable
The aim of the project is to get a passing grade. An inherent aim is to learn as much as possible
about IT governance and how it is used to govern the IT policies in businesses.
XVI
Summary milestone schedule
Date Task
Feb 5, 2017 Project plan completed
Feb 15, 2017 Key organization identified and contacted
Feb 20, 2017 Interview questions drafted
Feb 24, 2017 Interview conducted
March 10, 2017 Finish 1. deliverable
March 14, 2017 Deliver and present 1. deliverable
March 14, 2017 Distribute tasks for 2. deliverable
March 28, 2017 Deliver and present 2. Deliverable
XVII
Appendix D – Stakeholder management strategy
Our list of potential candidates consists of the following organizations:
Universitetets senter for informasjonsteknologi (USIT)
99x
Direktorat for forvaltning og IKT (Difi)
Oslo Stock Exchange (OSE)
We plan to contact the organization via email. We direct our communication towards the highest
ranking person available in the IT-unit of the organization, and hope they can point us in the right
direction. The person should be able to influence the IT-governance of said organization or at the
very minimum know how the IT-governance is organized. We would prefer a person that has
worked in the IT-department for a long time (10 years), this would make them able to give answer
historical context.
The preferred outcome would be a personal interview (30 minutes or so), with a senior IT man-
ager. It would also be advantageous if the IT manager was available for follow up questions.
XVIII
Appendix E – Communication Management Plan
The work on this project will in large part be divided between group members. The group mem-
bers should meet physically at least once before finalizing major events such as:
Finishing interview guide
Submitting deliverables
Giving presentations
To ensure good work flow, continuous communication is advised. Our primary channel is an
INF5890 chat group on Facebook where all group members are present and expected to join the
discussion.
Andreas Jensen Gjellesvik has arranged a document in Microsoft Office 365 that all group mem-
bers can contribute to simultaneously. We also encourage group members to make use of the
“comment” function and reviewing the work of other group members. This way we can ensure
that the document is cohesive and avoid double work.
Everyone is equally responsible for communicating, and a severe lack of communication could be
sanctioned.
Distribution for contributions for deliverable 1
Andreas Jensen Gjellesvik
Introducion
About OSE
Decision rights
Kristine Helen Lyngholm Næss
Interview transcription
Key systems and interconnections
Philip Strøm Anthonisen
Organizational structure
Concluding remarks
Distribution for contributions for deliverable 2
Andreas Jensen Gjellesvik
Business and IT principles
Project method
XIX
Kristine Helen Lyngholm Næss
Projects and project management
Philip Strøm Anthonisen
Governance arrangement
Project charter
Stakeholder management strategy
Communication management plan
![[PPT]Process Documentation - Forsiden - Universitetet i Oslo · Web viewProcess Documentation Dr.Zubeeda Quraishy Dept of Informatics University of Oslo, Norway Process Documentation](https://img.pdfslide.us/doc/110x75/5aefb9a77f8b9aa9168cff30/pptprocess-documentation-forsiden-universitetet-i-viewprocess-documentation.jpg)
![[The Health Information System in Sudan] - DUO - Universitetet i Oslo](https://img.pdfslide.us/doc/110x75/62074a7e49d709492c2ff163/the-health-information-system-in-sudan-duo-universitetet-i-oslo.jpg)