locked
O/T - Enterprise Service Environment RRS feed

  • Question

  • Hi All

     

    Sorry to ask it here - bit O/T but I've been learning a lot from the real-world discussions here and didn't know where else to ask.


    I'm currently trying to land a job in our architecture department. Done a paper for them already in my own time. I want one more done before the job comes up. But they've tasked me with a problem well out of my field of expertise. I have done BA training so I do understand the language.

    They want a short 3-5 page doc that covers an enterprise service environment. I'm to consider three areas:
    Business
    Application
    Hardware
    They haven't given me more detail than that but I'm assuming it's for validation and provisioning at a high level. I've got a few ideas but not 3-5 pages worth.

    The organisation is very interested in SOA at the moment and outsourcing. With all the work on ITIL, SOA, MOF etc. there must be something like this out there.

    The closest thing I've found so far is: http://www.jot.fm/issues/issue_2008_07/column4.pdf which is moving in the right direction but not granular enough.

    We have subscriptions to many on-line IT libraries - can somebody please point me to some links, books etc.

    Monday, July 7, 2008 1:47 AM

Answers

  • cabledguy:

     

    > Thanks for your reply

     

    You are welcome!

     

    > no problem statement - I'm afraid our management isn't that organised.

     

    Strictly speaking, it is up to the information consultant to guide the client to a definite problem statement (I'll leave aside matters on how definite that can be, and iterations, etc.): this is simply what requirements gathering and analysis stand for: it is our own responsibility, otherwise the client wouldn't need our expertise in the first place.

     

    That said: for various reasons, it might be the case that the client is not so willing to cooperate (quite uncommon), or it might be the case that it is our very management that is not willing to accept/understand/allow it (almost always). Then it is your decision: either you take it as it is, and possibly fill in the gaps with what is most confortable for *you* to develop, or you could do as I am not ashamed to tell you I do in 99% of the cases: a bye bye to fresher air.

     

    > I'm assuming its more of a design/provisioning checklist with some explanation eg.

     

    Going back to the problem at hand: those check-lists, and recipes, represent indeed the most wrong approach to software development ever. In any case, if that's what the customer dreams, then maybe just go on as you have planned in the next paragraph. In general, customers deserve what they are asking and paying for.

     

    > I'll write up some explanation and slot it into those frameworks and that will be enough for the draft.

     

    Even if I would just leave for better shores, I can understand and appreciate your approach there: indeed, I guess, it is the only reasonable approach (remaining).

     

    The best of luck.

     

    -LV

    Wednesday, July 9, 2008 1:46 AM
  • Difficult to architect a solution that has no initial problem definition!

    Are they asking you to make a scenario up, or describe what your approach to any problem is? 

    I'd also suggest that chasing buzzwords is not necessarily the best approach - better that you design an application based on a technology and design fit for purpose, or you're in for a world of hurt if you don't.

    SOA is so much more than a buzzword - you have to design your architecture correctly to even make this close to possible - ITIL and MOF aren't really buzzwords associated with the software architecture, more the management of a project.  All good to know, and the ITIL, and MOF / MSF approach would need to be decided upon a long time before SOA is chosen.

    Why do you want to use SOA?  Is there an actual reason, or is it more a case of just jumping on the bandwagon?  I'd respect any architect that much more for asking questions like that, rather than just following the crowd.  You could waste a lot of money following the crowd, if your particular situation doesn't warrant, or doesn't really make sense with SOA.

    Of course, if you're looking at SOA, you might also consider SaaS, which is a step on, and depending upon the services, and functionality that the company that you work for implements, may also be appropriate.

    I hope the few ideas get you thinking and help you with your career path!

    Thanks,

    Martin.
    MCSD, MCTS. Please mark my post as helpful if you find the information good!
    Sunday, April 5, 2009 10:31 AM

All replies

  • cabledguy:

     

    > They want a short 3-5 page doc that covers an enterprise service environment.


    > The closest thing I've found so far is: http://www.jot.fm/issues/issue_2008_07/column4.pdf which is moving in the right direction but not granular enough.

     

    What you mean by not granular enough? It's already 8 pages long. What are you after? Did they give you some specific enterprise problem to solve, or is it the universal enterprise domain that you have been asked to model? Something in between? Have you got a problem statement?

     

    -LV

    Monday, July 7, 2008 2:28 AM
  • Thanks for your reply - no problem statement - I'm afraid our management isn't that organised.

     

    I'm assuming its more of a design/provisioning checklist with some explanation eg.

    Business Architecture

    Business Criticality Rating

    Business Service(s) e.g. accounts reconiliation

    Service Owner: Mr Blah

    Service Unit: Financial Operations

    Technical Architecture

    Identity Service (i.e. authentication)

    DR requirements

    Virtualisation Potential (yes/no - constraints)

    Application Architecture

    Tier (i.e. local or enterprise application)

    Compents/Operating Environment

     

    Etc.  it's the etc I need ;-)  And since our latest buzzwords are ITIL and SOA - I'll write up some explanation and slot it into those frameworks and that will be enough for the draft. 

     

     

    Tuesday, July 8, 2008 11:18 PM
  • cabledguy:

     

    > Thanks for your reply

     

    You are welcome!

     

    > no problem statement - I'm afraid our management isn't that organised.

     

    Strictly speaking, it is up to the information consultant to guide the client to a definite problem statement (I'll leave aside matters on how definite that can be, and iterations, etc.): this is simply what requirements gathering and analysis stand for: it is our own responsibility, otherwise the client wouldn't need our expertise in the first place.

     

    That said: for various reasons, it might be the case that the client is not so willing to cooperate (quite uncommon), or it might be the case that it is our very management that is not willing to accept/understand/allow it (almost always). Then it is your decision: either you take it as it is, and possibly fill in the gaps with what is most confortable for *you* to develop, or you could do as I am not ashamed to tell you I do in 99% of the cases: a bye bye to fresher air.

     

    > I'm assuming its more of a design/provisioning checklist with some explanation eg.

     

    Going back to the problem at hand: those check-lists, and recipes, represent indeed the most wrong approach to software development ever. In any case, if that's what the customer dreams, then maybe just go on as you have planned in the next paragraph. In general, customers deserve what they are asking and paying for.

     

    > I'll write up some explanation and slot it into those frameworks and that will be enough for the draft.

     

    Even if I would just leave for better shores, I can understand and appreciate your approach there: indeed, I guess, it is the only reasonable approach (remaining).

     

    The best of luck.

     

    -LV

    Wednesday, July 9, 2008 1:46 AM
  • Difficult to architect a solution that has no initial problem definition!

    Are they asking you to make a scenario up, or describe what your approach to any problem is? 

    I'd also suggest that chasing buzzwords is not necessarily the best approach - better that you design an application based on a technology and design fit for purpose, or you're in for a world of hurt if you don't.

    SOA is so much more than a buzzword - you have to design your architecture correctly to even make this close to possible - ITIL and MOF aren't really buzzwords associated with the software architecture, more the management of a project.  All good to know, and the ITIL, and MOF / MSF approach would need to be decided upon a long time before SOA is chosen.

    Why do you want to use SOA?  Is there an actual reason, or is it more a case of just jumping on the bandwagon?  I'd respect any architect that much more for asking questions like that, rather than just following the crowd.  You could waste a lot of money following the crowd, if your particular situation doesn't warrant, or doesn't really make sense with SOA.

    Of course, if you're looking at SOA, you might also consider SaaS, which is a step on, and depending upon the services, and functionality that the company that you work for implements, may also be appropriate.

    I hope the few ideas get you thinking and help you with your career path!

    Thanks,

    Martin.
    MCSD, MCTS. Please mark my post as helpful if you find the information good!
    Sunday, April 5, 2009 10:31 AM