On one particular programme the question arose whether to create the "Enterprise Architecture" or the "Requirements" first has been a matter of great debate. On the one hand, the organisation in question did not have an Architecture and yet the organisation's aim was to engage in a major transformation. There was no baseline, no standard operating procedures nor were there any governance or directive documents.
Due to time limitations, the architecture team decided that the first thing that they would do would be to capture the Enterprise Architecture. They followed an academically correct method in working out how the organisation was structured, their roles, responsibilities, business rules and processes. It was a classic engagement.
The only problem was, that they did not capture the requirements as they were going along, even more so, they did not use the customer needs and desires to form the "germ" requirements.
What transpired was that they created an AS-IS Architecture and extrapolated this to derive the deltas that would make up the TO-BE Architecture. While this was extremely clever, it was prohibitively expensive in that every functional area was exhaustively explored and the client staff were engaged in a whole plethora of workshops. The Enterprise Architecture developed consisted of very detailed series of models and to all intents and purposes it could have worked.
But.....
There is always a but.... In the haste to capture all the information, the cardinal rule of Enterprise Architecture was forgotten. That there needs to be an agreement on method, meta model, consistency in modelling approach, agreed conventions and structure to coordinate the use of key and common elements in a repository. What ensued was duplication and multiple core objects and architecture elements, inconsistency in structure and so many models that actually you couldn't see the wood for the trees and finding meaningful models was proving to be difficult.
One aspect for lack of cohesion can be found in the human dimension. The architects were not working as a cohesive team. An engagement with a number of architects require discipline, control and a central point who will be responsible for ensuring that the architecture is consistent.
Nevertheless, this does not change the fact that these engagements can produce an inordinate number of models and as true to form, when they were analysed to form requirements, even though they had captured the behaviour and structure of the intended architecture it still lacked some of the qualitative dimensions in terms of performance, non functional and decorative aspects. The result was a well formed enterprise architecture, however, the requirements had to be developed on the gallop and quality suffered. The result was that the client was not pleased. They had bought into the idea that a perfectly formed
To bring the engagement back on track a Lean approach was taken, to select the key models needed for the development of requirements and the structuring of Enterprise Level requirements from which system, operational and business requirements would flow.
The Lean method states that before an Enterprise Architecture is undertaken that there should be requirements. In many cases these will form the parameters and scope of an engagement and will determine the key purpose of the architecture and organisational strategic goal. These requirements need to be measurable in order to understand how the Enterprise Architecture can be judged as to whether or not it is fit for purpose. These requirements direct the development of an Enterprise Architecture and subsequent prioritisation and specification of requirements at all levels of the enterprise.
It must be said that Lean has proved to have been a very useful method to develop an Enterprise Architecture to create a coherent set of models with associated requirements in a fraction of the time taken for the programme above. Granted it did not try and boil the ocean, but took discrete areas that needed treatment and brought these into a coherent set of models that could be integrated into the Enterprise continuum.
18 Feb 2012
Evolution of a career ...
My career started in the true meaning of the word - I found myself careering like a go-cart out of control downhill. It is said that "necessity is the mother of invention"; this applied to my mindset as a teenager faced with the reality that as soon as I left school my bags and my person would be out on the streets and I would have to find my own way in life. I blundered through A levels, not quite sure where I was going. Like many young people, there would be a command from on high with instructions on "the types of career that would be acceptable", however, if one is not destined or does not have the aptitude, one is rather stuck.
We didn't have the Internet, nor Job Boards, we had the Unemployment Office of the DHSS. As a teenager these places looked daunting, impossible, so I turned to newspapers. They actually had real job there, but they were few and far betweeh.
In a flash of inspiration I took to the Yellow Pages, that is where we would look if we were looking to find anything, so the job hunting started with the first section, under "A".
Accounting - not for me, couldn't see myself just doing sums, Apothecary, no...
Banking - a distinct possibility so I sent out a whole flock of letters to various banks and lo and behold, I landed a job.
I was totally unprepared for the British mysogenistic banking world of the 1980s where I witnessed highly qualified and talented women being passed over in favour of men with the brains and charm of a monkey. It came to a crossroads and I decided to change tack purely by chance into insurance where I found underwriting and dealing with claims highly entertaining and ended up with my own department looking after marine, engineering, commercial property with small business risks.
However, the systems we used were suboptimal, any data entry was laborious and I soon had the idea that I would like to change the business processes and the systems. There was a wave of change going through the banking and financial sectors where back office work was being automated, jobs were moving from the banking floor to IT systems. There was an opportunity to embrace the technical side of business systems, which was just fascinating.
My own path was changed irrevocably with the advent of three children, who became fellow travellers on the journey through college and university to study information technology and business information, they even accompanied me to my lectures in Strategic Management. I thought they were all naturals. Still, they all have their own university degrees and are playing their own role in their own stories.
The first job I found was by pure chance, I happened to be shopping and happened to have a briefcase, a freshly printed CV and gaggle of kids when I spotted a poster that Hyder was hiring. I managed to sell the idea to a recruiter that they needed an IT and Business hybrid graduate and was invited to an interview for a Business Analyst. Now I thought that meant Financial analysis, but it was the analysis of systems and development of a coprorate business process model and information model using ERwin and BPwin, which were the beginnings of an Enterprise Architecture. Later Popkin built their System Architect modelling software with ERwin and BPwin at the core. Even the IDEF modelling was embedded.
What is hard is the uncertainty of it all, when you are trying to raise a bunch of otters who don't really understand why their mother is preoccupied still with reading new methods, techniques and playing around with interactive and collaborative software. To be honest, without a partner the children would have greatly suffered and worse still, they didn't understand, in fact I doubt that they understand what life would have been like without a dad.
The UK is no place to be a single parent. Europe offered far greater opportunities since as a mother you are not treated any differently from all the other workers. We all, men and women, were parents, partners, sons, daughters and all had equal role in family life. The work life balance was extremely important and as such, it meant that people made solid decisions that were taken calmly, deliberately and with consensus.
The Anglo-American work environment would do well to learn lessons from these more efficient and effective models. It is well documented that longer hours do not improve productivity, in fact, the contrary. As a mother, balancing the needs of family and the imperative need to deliver. There is, nevertheless, an over riding tendency to over compensate, probably down to a perception that so much effort is put into children that work also requires an equal if not more attention, especially to delivery. The plus side, I've never had a pub or bar to support.
I have wondered if my partner, long suffering as he is, would expect to perform as much as I do as a professional and carry so much of the domesticities on top of this, but I have plenty of male counterparts who also do their equal share.
Maybe it is our industry, but I thank the Lord that I'm not expected to go to work caked in make up the way I watched the manikins totter into the banks in the 1980s. That was gruesome. I would say that IT is one of the best industries for women, we need more of them to take up systems engineering and come and join us. The greater the diversity of background, race, sex, age, orientation the better, we all bring something different, a new perspective to our work and collaboration.
We didn't have the Internet, nor Job Boards, we had the Unemployment Office of the DHSS. As a teenager these places looked daunting, impossible, so I turned to newspapers. They actually had real job there, but they were few and far betweeh.
In a flash of inspiration I took to the Yellow Pages, that is where we would look if we were looking to find anything, so the job hunting started with the first section, under "A".
Accounting - not for me, couldn't see myself just doing sums, Apothecary, no...
Banking - a distinct possibility so I sent out a whole flock of letters to various banks and lo and behold, I landed a job.
I was totally unprepared for the British mysogenistic banking world of the 1980s where I witnessed highly qualified and talented women being passed over in favour of men with the brains and charm of a monkey. It came to a crossroads and I decided to change tack purely by chance into insurance where I found underwriting and dealing with claims highly entertaining and ended up with my own department looking after marine, engineering, commercial property with small business risks.
However, the systems we used were suboptimal, any data entry was laborious and I soon had the idea that I would like to change the business processes and the systems. There was a wave of change going through the banking and financial sectors where back office work was being automated, jobs were moving from the banking floor to IT systems. There was an opportunity to embrace the technical side of business systems, which was just fascinating.
My own path was changed irrevocably with the advent of three children, who became fellow travellers on the journey through college and university to study information technology and business information, they even accompanied me to my lectures in Strategic Management. I thought they were all naturals. Still, they all have their own university degrees and are playing their own role in their own stories.
The first job I found was by pure chance, I happened to be shopping and happened to have a briefcase, a freshly printed CV and gaggle of kids when I spotted a poster that Hyder was hiring. I managed to sell the idea to a recruiter that they needed an IT and Business hybrid graduate and was invited to an interview for a Business Analyst. Now I thought that meant Financial analysis, but it was the analysis of systems and development of a coprorate business process model and information model using ERwin and BPwin, which were the beginnings of an Enterprise Architecture. Later Popkin built their System Architect modelling software with ERwin and BPwin at the core. Even the IDEF modelling was embedded.
What is hard is the uncertainty of it all, when you are trying to raise a bunch of otters who don't really understand why their mother is preoccupied still with reading new methods, techniques and playing around with interactive and collaborative software. To be honest, without a partner the children would have greatly suffered and worse still, they didn't understand, in fact I doubt that they understand what life would have been like without a dad.
The UK is no place to be a single parent. Europe offered far greater opportunities since as a mother you are not treated any differently from all the other workers. We all, men and women, were parents, partners, sons, daughters and all had equal role in family life. The work life balance was extremely important and as such, it meant that people made solid decisions that were taken calmly, deliberately and with consensus.
The Anglo-American work environment would do well to learn lessons from these more efficient and effective models. It is well documented that longer hours do not improve productivity, in fact, the contrary. As a mother, balancing the needs of family and the imperative need to deliver. There is, nevertheless, an over riding tendency to over compensate, probably down to a perception that so much effort is put into children that work also requires an equal if not more attention, especially to delivery. The plus side, I've never had a pub or bar to support.
I have wondered if my partner, long suffering as he is, would expect to perform as much as I do as a professional and carry so much of the domesticities on top of this, but I have plenty of male counterparts who also do their equal share.
Maybe it is our industry, but I thank the Lord that I'm not expected to go to work caked in make up the way I watched the manikins totter into the banks in the 1980s. That was gruesome. I would say that IT is one of the best industries for women, we need more of them to take up systems engineering and come and join us. The greater the diversity of background, race, sex, age, orientation the better, we all bring something different, a new perspective to our work and collaboration.
Enterprise Architecture: Bringing Policy into the realms of Reality
Many policy makers spend their time in the strategic stratosphere, shaping policy, doctrine and initiatives with fellow policy makers. They dwell in the realm of politics and deliberate on concepts towards greater good of countries, regions and establishments together with think tanks, advisors and academic hubs. All important and highly valuable, however, there comes a point when questions need to be asked of these policies, how can they be evaluated and linked to actionable implementation.
Enterprise Architecture can provide a vehicle and a means to visualise the goals and objectives derived from these policies and when they are compared with capabilities of the existing initiatives that have been implemented it is possible to estimate costs and projected benefits.
One of the important questions that we pose to policy makers is for them to describe what they have in their mind in terms of ... what does "good" look like? How do they envisage their policies being implemented and start the journey of consideration of reality and implication.
From this analysis we look at the art of the possible. Everything has a cost, thus the question: what are the priorities? What are the timelines and what is the forecasted cash flow required to achieve these? Thus programme mandates are derived with traceability to required goals in fulfillment of policy. This is important evidence for helping to evaluate the effectiveness of a strategic business plan.
When we come across policy advisors who fail to make the connection to reality we have to ask where they are going and what, indeed are their own objectives and what is their agenda. It might be a good idea to do some background research into the goals and objectives of policy advisors to ensure that they align with those of the company.
We have come across advisors and researchers whose own business model lies on the basis of selling their own services, including PR exercises, Roadshows, Conferences and Conclaves and not necessarily on provision of advice that can be implemented in measurable, quantifiable programme initiatives. Enterprise Architecture and Analysis is therefore an important way to evaluate the coherence of these policies and a match with the enterprise resource capabilities and capacities.
Enterprise Architecture can provide a vehicle and a means to visualise the goals and objectives derived from these policies and when they are compared with capabilities of the existing initiatives that have been implemented it is possible to estimate costs and projected benefits.
One of the important questions that we pose to policy makers is for them to describe what they have in their mind in terms of ... what does "good" look like? How do they envisage their policies being implemented and start the journey of consideration of reality and implication.
From this analysis we look at the art of the possible. Everything has a cost, thus the question: what are the priorities? What are the timelines and what is the forecasted cash flow required to achieve these? Thus programme mandates are derived with traceability to required goals in fulfillment of policy. This is important evidence for helping to evaluate the effectiveness of a strategic business plan.
When we come across policy advisors who fail to make the connection to reality we have to ask where they are going and what, indeed are their own objectives and what is their agenda. It might be a good idea to do some background research into the goals and objectives of policy advisors to ensure that they align with those of the company.
We have come across advisors and researchers whose own business model lies on the basis of selling their own services, including PR exercises, Roadshows, Conferences and Conclaves and not necessarily on provision of advice that can be implemented in measurable, quantifiable programme initiatives. Enterprise Architecture and Analysis is therefore an important way to evaluate the coherence of these policies and a match with the enterprise resource capabilities and capacities.
Subscribe to:
Posts (Atom)