Getting Organized for SOA Success Part II

July 9, 2009

In the previous post on getting organized for succeeding with SOA I talked about the importance of implementation-free requirements and the overall role of business analysts. In this post, I would like to highlight specific areas where business analysts can help SOA initiatives.

  • Create business models – free of technical specifications or system level details – that capture the full end-to-end view of a business process. They should use a modeling tool that can work with a standard notation (e.g. BPMN) and create as accurate a view of a business process as possible. They need to capture human steps, system steps, pauses, business rules, external activities, etc. accurately and comprehensively
  • Identify candidate business capabilities – not necessarily technical services – but at a higher level of abstraction. For example, MakePayment or BookTicket are business capabilities that can be realized in a multitude of ways by technology folks. But the analysts could significantly help by pointing out capabilities that are candidates for reuse across multiple business processes, scenarios, or lines of businesses.
  • Identify areas for simplification/streamlining – analysts can identify redundant manual steps where users enter data multiple times or in similar fashion. They can also identify steps that can be eliminated or made simpler. For instance, validating credit worthiness of a customer could be done systematically and the system can present options for the user based on score. Or the credit worthiness score could be driven by business rules and only in exception cases the system might require manual intervention. All these behaviors have to be driven from the context of how to make the overall user experience better.
  • Provide context – analysts can help identify areas of business priority in order for technology to build services. What lines of businesses are meant to grow? which ones are going away? which business process needs maximum customization and if so, in what ways? A good analyst can provide the big picture view, the context for your SOA initiatives by helping you separate the essential from all the noise.

This list isn’t exhaustive but is meant to give a sense of the key role that an analyst plays!

Like this post? Subscribe to RSS feed or get blog updates via email.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :

Advertisements

Why Developers Resist Reuse? New podcast episode

July 5, 2009

Want to listen using iTunes?

Using iTunes?

podcastA new episode is added on the Software Reuse podcast series. This new episode explores why developers resist reusable assets (e.g.Β  fear of needless complexity, lack of trust, timing of integration with the codebase etc.) and provides ideas on addressing the hurdles.

Like this post? Subscribe to RSS feed or get blog updates via email.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :


Software Reuse Tips Article

June 23, 2009

Article on software reuse tips recently got published at infoq.com…

infoq Here is the link:

http://www.infoq.com/articles/vijay-narayanan-software-reuse

Like this post? Subscribe to RSS feed or get blog updates via email.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :


Minimize Jargon and Maximize Relevance

June 5, 2009

How many times have you talked to a technologist who uses a lot of jargon? MDA, SSO, SAAS, BPELWS . As a technologist I am guilty of using jargon as well πŸ™‚ However, if you want to turn people off specially when you are trying to influence and persuade them there is no better way than to use excessive jargon! confused

Software reuse is a hard problem mainly because a lot of us get buried in the technical aspects and ignore everything else. If you want to successfully communicate with developers and development leads minimize the jargon and refrain from showing off your technical superiority. Instead, focus on relevance. If you understand the problem and can truly add value by pointing them towards a reuse friendly solution more power to you. Too often I see just the opposite – anxious to force solutions technologists decide on the approach using a favorite technology (they freely sprinkle arcane terms and acronyms to intimidate coworkers) and then wonder why people resist.

When you encounter a problem pause and reflect – strive to understand the bigger picture:

  1. who is asking for the functionality?
  2. is this a one-time requirement or something that is relevant to multiple applications?
  3. have we solved this problem before within the team?
  4. do we have something that could work with some refactoring?

These are the questions that will get you closer to success with reuse. Focus less on the technology and more on the problem and relevance. Watch your developers become more adept at recognizing which functions need to be reusable and which ones aren’t.

I am not for a second saying technology is irrelevant or unimportant. Far from that. Before the how you have to figure out the what and technology is good with the latter. Framing reuse within the problem at hand will make it easier for you to convince folks within and outside your team. Try it and surprise yourself!

Like this post? Subscribe to RSS feed or get blog updates via email.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :


Transitioning from Waterfall to Agile on a large SOA Project

May 31, 2009

Last week I spoke at the International Association of Software Architects (IASA) New York chapter’s monthly meeting on Transitioning from Waterfall to Agile on a Large SOA Project. Here is a quick summary:

Challenges

  • Changing business mindset that the project will be released in production as a single deliverable
  • Convincing the business to prioritize requirements
  • Enlisting your business stakeholders to be part of a unified team.
  • Maintaining the project plan within the context of agile
  • Making the case for following agile instead of the official development process
  • Preparing to address the fear, uncertainly, and doubt (FUD) factor with learning agile practices
  • Integrating agile with IT processes – iteration planning with program management specifically cross project dependencies, incremental releases with release management and incident management, and incremental design with enterprise architecture and governance
  • Adopting agile practices – which methodology to adopt? Which practices to follow?
  • Integrating distributed teams into the iteration planning and daily stand up.
  • Understanding the impact of integration with several systems and legacy processes
  • Identifying the right level of granularity to be added to the task list

Lessons Learned

  • Business stakeholders are more likely to buy into incremental delivery if it is explained in terms of faster return on investment, earlier end user feedback, and risk reduction
  • Collaborate with your business on identifying and prioritizing user stories. Focus on the absolute essential stories and ruthlessly cull the rest.
  • Timebox your iterations – the standard β€œ2 week” sprints may not be enough for development and integration testing.
  • Engage with your QA team ahead of the formal testing phase. Enlist their support to develop more comprehensive test cases during development.
  • The project plan might never go away! However, the task list can be the primary source of input into updating the plan as well as help reflect true project state
  • Prototype – even if it is entirely paper based – by having business and technology together to foster joint problem solving and a sense of shared ownership
  • Include business participation in daily stand up meeting, iteration demo, and retrospective
  • Consider dedicated stand up meeting for remote teams – have reps for daily meetings
  • If you are unable to convince release management to be comfortable with continuous delivery have internal releases and align with published release dates
  • Adopt agile practices slowly – it is important to be consistent and disciplined rather than adopting several practices in a haphazard manner
  • Pursue continuous integration in an incremental manner – you don’t have to get multiple layers and technologies all part of the daily build from day one.
  • Strive to standardize tools in order to simplify tracking and reporting. Use a simple tool like a wiki before switching to a full blown issue tracking tool.
  • Keep a close eye on the iteration backlogs. You cannot only estimate and plan for new functionality

Candidate list of agile practices to start with:
Daily standup meetings, incremental design, done-done, iteration planning, continuous integration, retrospectives and iteration demo.

Like this post? Subscribe to RSS feed or get blog updates via email.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :


Systematic Software Reuse Mindmap

May 2, 2009

software reuse mindmapI created a mind map on systematic software reuse. The key ideas:

Like this post? Subscribe to RSS feed or get blog updates via email.

add to del.icio.us: Digg it : post to facebook: Stumble It! : :


Having Reuse-Friendly conversations

April 26, 2009

You approach a developer with an idea for a reusable software component or service. What do you typically hear as an answer? I typically hear variations of the same answers.Β  What do you when you hear these? Do you accept and give up? or attempt to persuade? if you are like me you want to persuade the developer. Here is a brief presentation on doing just that:

Like this post? Subscribe to RSS feed or get blog updates via email.

add to del.icio.us: Digg it : post to facebook: Stumble It! :


%d bloggers like this: