Skip to main content
MENU CLOSE

Cyber collapse causes chaos for the Galactic Senate.

The opening crawl of Star Wars Episode II: Attack of the Clones, states the following:

There is unrest in the Galactic Senate. Several thousand solar systems have declared their intentions to leave the Republic. 

This separatist movement, under the leadership of the mysterious Count Dooku, has made it difficult for the limited number of Jedi Knights to maintain peace and order in the galaxy. 

Senator Amidala, the former Queen of Naboo, is returning to the Galactic Senate to vote on the critical issue of creating an ARMY OF THE REPUBLIC to assist the overwhelmed Jedi…

Unbeknownst to Senator Amidala, her vote on the creation of an Army of the Republic was meaningless because this army was already being created in a conspiracy dating back long before Jar Jar Binks single-handedly ruined Episode I… But I bet someone in the Senate knew!

One thing that our world and the Star Wars galaxy both have in common is the importance of well functioning and comprehensive, coherent IT. It is clearly evident that the Galactic Senate had no such thing and as a result the Jedi Knights were being hindered in their peace keeping function, important information was not being communicated to Senator Amidala, and the poor woman had to travel across galaxies and suffer numerous assassination attempts in order to convey a simple instruction. If only an IT Dispute specialist had advised the Senate on the best practice for implementing an IT system….

An up to date IT system is at the core of most of the best performing organisations. When it works well, no one notices, but when there’s a problem, there’s usually no one who fails to notice.

How has the Senate ended up with a failing system? It may have inherited systems from previous governments or other organisations it has acquired; alternatively parts of the Administration may have upgraded or purchased different technologies which may have assisted that particular group. There may have been financial constraints which meant that other requirements were a priority or that not all parts (or any part) of the Senate received the necessary upgrade. The net result can be a patchwork quilt of IT support.

Unfortunately within the Senate, users, both legacy and lateral may have become used to their own particular technology and may be reluctant to move away from it. From an efficiency perspective, it may mean that parts of the Senate are unable to communicate with each other, or more importantly, it might mean that it is not possible to gather data on how well each part of the Senate is performing or to ensure that the organisation is complying with regulations and therefore to spot any wrongdoing.

In principle, a case for a new system can easily be made out on paper.  The challenge is how to arrive at such a system and to implement it.

Firstly, a Senator who understands the way the Senate really works and the IT options available should lead the project to ensure that the system will meet its requirements. What are those requirements? Capturing and managing them for a specification is not straightforward, particularly when the Senate has a wide range of stakeholders with differing requirements. If the Senate is to ensure that the project is successful, and that the system is embraced by all users, it must make sure it meets their needs. This requires a detailed understanding of how they all use the system, however sometimes not all users are cooperative in describing or are unable to articulate their requirements. Will the new project have the support and buy in from senior Senators to ensure that users will comply with requests for information? If they do not engage in the project and lead by example, it can mean that the implementation is a much longer and therefore costlier exercise.

Using a model group of adopters to pilot a system is a sensible approach however is unlikely to work if that group is not representative of the whole when tasked with defining a specification to be adopted by all. This may be the troubled background even before a supplier starts the build.

Secondly, putting the IT supply contract out to tender to several suppliers usually involves a rapid bid process, which inevitably may be finalised before the Senate has given itself time to understand what it needs and to carry out a rigorous requirements gathering exercise.

The time between tender and contract signing can be short and the Senate could be at a fateful disadvantage as a supplier sets out what it is contracted to supply, which may not necessarily be what the Senate wants or needs. It may be reassuring for the Senate to insist on bid documents being incorporated into the contract, only to find later that they are in reality a sales pitch and aspirational without any obligation on the supplier. Similarly, by the time the Senate realises what the specification should contain, it may be too late and any changes will need to be dealt with through amendments to the contract. Such changes invariably carry additional charges and therefore the system the Senate thought it was acquiring for a fixed price can soon threaten, if not blow, the budget.

Other challenges on a new implementation can be that the new system is unlikely to involve a simple transfer of data from several legacy systems to a new system – but rather a transformation of all the required data into the format for the new system. The cost between a transfer and transformation is usually significant. Does the Senate know the full extent of the applications its members and Jedi are using and which applications it is necessary to transform in order for them to carry out their day to day functions?

The system is usually considered accepted after certain testing but there may be a disparity between when the supplier considers the testing should end and what the Senate considers to be an acceptably performing system.

The potential pitfalls are significant and wide ranging but with some forethought and planning, there is every reason to believe that the Senate should be able to enjoy the numerous and undoubted benefits of a new IT system and avoid being toppled by the separatist rebel movement.

Bivonas Law LLP

Bivonas Law was established in 1997 and from the outset has acted in serious criminal and regulatory investigations, together with a number of notorious commercial disputes.

The opening crawl of Star Wars Episode II: Attack of the Clones, states the following:

There is unrest in the Galactic Senate. Several thousand solar systems have declared their intentions to leave the Republic. 

This separatist movement, under the leadership of the mysterious Count Dooku, has made it difficult for the limited number of Jedi Knights to maintain peace and order in the galaxy. 

Senator Amidala, the former Queen of Naboo, is returning to the Galactic Senate to vote on the critical issue of creating an ARMY OF THE REPUBLIC to assist the overwhelmed Jedi…

Unbeknownst to Senator Amidala, her vote on the creation of an Army of the Republic was meaningless because this army was already being created in a conspiracy dating back long before Jar Jar Binks single-handedly ruined Episode I… But I bet someone in the Senate knew!

One thing that our world and the Star Wars galaxy both have in common is the importance of well functioning and comprehensive, coherent IT. It is clearly evident that the Galactic Senate had no such thing and as a result the Jedi Knights were being hindered in their peace keeping function, important information was not being communicated to Senator Amidala, and the poor woman had to travel across galaxies and suffer numerous assassination attempts in order to convey a simple instruction. If only an IT Dispute specialist had advised the Senate on the best practice for implementing an IT system….

An up to date IT system is at the core of most of the best performing organisations. When it works well, no one notices, but when there’s a problem, there’s usually no one who fails to notice.

How has the Senate ended up with a failing system? It may have inherited systems from previous governments or other organisations it has acquired; alternatively parts of the Administration may have upgraded or purchased different technologies which may have assisted that particular group. There may have been financial constraints which meant that other requirements were a priority or that not all parts (or any part) of the Senate received the necessary upgrade. The net result can be a patchwork quilt of IT support.

Unfortunately within the Senate, users, both legacy and lateral may have become used to their own particular technology and may be reluctant to move away from it. From an efficiency perspective, it may mean that parts of the Senate are unable to communicate with each other, or more importantly, it might mean that it is not possible to gather data on how well each part of the Senate is performing or to ensure that the organisation is complying with regulations and therefore to spot any wrongdoing.

In principle, a case for a new system can easily be made out on paper.  The challenge is how to arrive at such a system and to implement it.

Firstly, a Senator who understands the way the Senate really works and the IT options available should lead the project to ensure that the system will meet its requirements. What are those requirements? Capturing and managing them for a specification is not straightforward, particularly when the Senate has a wide range of stakeholders with differing requirements. If the Senate is to ensure that the project is successful, and that the system is embraced by all users, it must make sure it meets their needs. This requires a detailed understanding of how they all use the system, however sometimes not all users are cooperative in describing or are unable to articulate their requirements. Will the new project have the support and buy in from senior Senators to ensure that users will comply with requests for information? If they do not engage in the project and lead by example, it can mean that the implementation is a much longer and therefore costlier exercise.

Using a model group of adopters to pilot a system is a sensible approach however is unlikely to work if that group is not representative of the whole when tasked with defining a specification to be adopted by all. This may be the troubled background even before a supplier starts the build.

Secondly, putting the IT supply contract out to tender to several suppliers usually involves a rapid bid process, which inevitably may be finalised before the Senate has given itself time to understand what it needs and to carry out a rigorous requirements gathering exercise.

The time between tender and contract signing can be short and the Senate could be at a fateful disadvantage as a supplier sets out what it is contracted to supply, which may not necessarily be what the Senate wants or needs. It may be reassuring for the Senate to insist on bid documents being incorporated into the contract, only to find later that they are in reality a sales pitch and aspirational without any obligation on the supplier. Similarly, by the time the Senate realises what the specification should contain, it may be too late and any changes will need to be dealt with through amendments to the contract. Such changes invariably carry additional charges and therefore the system the Senate thought it was acquiring for a fixed price can soon threaten, if not blow, the budget.

Other challenges on a new implementation can be that the new system is unlikely to involve a simple transfer of data from several legacy systems to a new system – but rather a transformation of all the required data into the format for the new system. The cost between a transfer and transformation is usually significant. Does the Senate know the full extent of the applications its members and Jedi are using and which applications it is necessary to transform in order for them to carry out their day to day functions?

The system is usually considered accepted after certain testing but there may be a disparity between when the supplier considers the testing should end and what the Senate considers to be an acceptably performing system.

The potential pitfalls are significant and wide ranging but with some forethought and planning, there is every reason to believe that the Senate should be able to enjoy the numerous and undoubted benefits of a new IT system and avoid being toppled by the separatist rebel movement.

Bivonas Law LLP

Bivonas Law was established in 1997 and from the outset has acted in serious criminal and regulatory investigations, together with a number of notorious commercial disputes.

Bivonas Law LLP

About the author

Bivonas Law LLP

Bivonas Law was established in 1997 and from the outset has acted in serious criminal and regulatory investigations, together with a number of notorious commercial disputes.