Oracle tools in the Enterprise Architecture world - part 2

Oracle tools in the Enterprise Architecture world - part 2

In April I have kept a presentation about the Oracle tools in the Enterprise Architect world on the Hungarian Oracle User Group (HOUG) conference in the database section. 

Topics of the presentation

• Introduction of the Enterprise Architecture 
• What is EA?
• TOGAF
• Oracle EAF
• Oracle solutions
• Oracle products in the Enterprise Continuum
• OAEF data governance
• Data as a Service place
• Solution for system governance

The first post was talked about the introduction of the EA and TOGAF, OEAF frameworks . This post is the second one which is giving examples for categories of the Enterprise Continuum of TOGAF.  The third one will contain all remaining topices

Oracle tools in the Enterprise Architecture world - part 1

Oracle tools in the Enterprise Architecture world - part 1

In April I have kept a presentation about the Oracle tools in the Enterprise Architect world on the Hungarian Oracle User Group (HOUG) conference in the database section. 

Topics of the original presentation

• Introduction of the Enterprise Architecture 
• What is EA?
• TOGAF
• Oracle EAF
• Oracle solutions
• Oracle products in the Enterprise Continuum
• OAEF data governance
• Data as a Service place
• Solution for system governance

Because of largeness of these topics I have splitted into three post. This blog post will talk about the introduction of the EA. The other two one will give some Oracle solution examples for some EA category. (part 2, part 3)

Useful strategy documents that help in going live

Useful strategy documents - part 4.

Finally I have reached my latest post in the useful strategy document series.

Now I would like to talk about the

• going live procedures
• handover/takeover criterias
• acceptance/goal criterias

Why are they so important? Because they could be the most important documents near the going live milestone. It's very important for both side, for the solution provider as well as for the customer too.
Usually what happens on a project? At the first phase of a project lots of people sit together to plan the whole project, the resources, the timeline, the milestones etc. Once the project team decide when will be the Going Live Date (GLD) then ones modify again the whole project plan to ensure that all design, all implementation, all develop, all test step will be finished until that point. So we plan everything but we usually create plan only from one viewpoint, from the first step viewpoint. What I mention is to create new viewpoints and create plans for these viewpoint then merge all plans into the final project plan.

What are these viewpoints?

• What steps should be done near GLD, how will the project's outcome go into production?
• How will done the takeover, when the solution providers team member give all maintance responsibilites to the customer team members. 
• Who and how will accepted the outcome.

So let's go through them

Useful project's strategy documents - Test strategy

Useful strategy documents - part 3.

Next project's strategy document is test strategy. 

"It depends on" Have you ever heard it? Of course yes. The content of a test strategy document is one best example for this type of answer sentence. Why I am saying it? Think on it a little bit. You could be one of the best test manager, tester, testing software user, your are doing the best job during software testing and your project could'nt be a success story if your project hasn't got this informations well defined and approved(!) by the customer:

• Project scope
• Acceptance/goal criterias
• System requirements
• High level use cases
• Architectures (hardware/software or business/data/application/technology)

Why are they important for us? Because they are the elementary input information for a succesful testing. If you are lucky and your customer or your company already implemented one of the architecture frameworks (TOGAF, Zachman etc) and reached the planning step (for example in TOGAF the F. Migration Planning step) than they are already well documented and accesible before your implementation project started. If not it doesn't mean that they are not available, hopefully your project team already realized they necessarity and created them during the project's progress.

So first let's go through them, then I will try to mention a skeleten for the test strategy document.