Tag Archive: Software Development


Solutions Architect -vs- Senior Principal Consultant

Filed under: Emotional Intelligence, Enterprise Architecture, Random Work Day Thoughts — Leave a comment
December 19, 2009

There are well known discrepancies in the software industry as to the definition of a Solutions Architect and a Senior Principal Consultant. Depending on what type of organization you speak to, you might get completely different answers to this question.

According to Wikipedia;

A Solutions Architect in Enterprise Architecture is a practitioner in the field of Solution Architecture.[1]

The role title has a wider meaning in relation to solving problems, but is more often used in the narrower domain of Technical architecture – the context for the remainder of this definition. In this context, the Solutions Architect is a very experienced architect with cross-domain, cross-functional and cross-industry expertise. He/she outlines solution architecture descriptions, then monitors and governs their implementation.

The role of “Solutions Architect” requires knowledge and skills that are both broad and deep. To be effective the Solutions Architect must have experience on multiple Hardware and Software Environments and be comfortable with complex heterogeneous systems environments. The Solutions Architect is often a highly seasoned senior technocrat who has led multiple projects through the Software development process or Systems Development Life Cycle (SDLC), and has usually performed in a variety of different roles in that life cycle. The person needs an ability to share and communicate ideas both verbally and in writing to executive staff, business sponsors, and technical resources in clear concise language that is the parlance of each group.”

Strangely Wikipedia does not have a definition for Senior Principal Consultant.   So based on the fact that I have been one for a number of years I have developed my own definition.

A Senior Principal Consultant is a practitioner of Software Solutions Architectures. Providing consulting services to clients, with a broad range of industry experience and knowledge.

This role requires the individual  to be the lead architect, designing implementation architectures as well as defining the development and roll out strategy.   The Senior Principal Consultant must work with multiple layers of an organization, from executes, to business stakeholders, to technical teams and be successful working in all circles.  They must be able to to communicate ideas to all levels and obtain buy in from both the business and technical organizations for their solution architectural designs.

This person must also poses a deep understanding of the business domain as well as the technologies used to solve the different business problems.  A typical Senior Principal Consultant is involved in all phases of a project lifespan from initial requirements gathering, architectural design, task break down, development (where they often act as a software architect and developer), testing, and then eventually roll-out into production.

After reading these two definitions it’s easy to see the confusion in our industry.  Both require depth of knowledge within the business and technical domains.  Both roles require the ability to articulate an architecture to project stakeholders, as well as technical audiences.   Where they differ however, and this is the key, is that the Senior Principal Consultant is more hands on, rather than removed from the implementation.

With that said however, most Solutions Architects I know also love working within the technology space so that they can gain a full understanding of it’s capabilities.  The difference though is that a Solutions Architect is not actually expected to perform the work needed to construct the solution.  They are simply responsible for directing the technical teams, who task it is to build the solution.

My bottom line however, is that the type of person needed for both positions is effectively the same with only minor differences relating to the types of tasks that are performed on a day to day basis.

Tags: , , , , , ,
Comment

Software Development Is Not Like Building a Car – Part III

Filed under: Emotional Intelligence, Project Management — Leave a comment
July 16, 2009

When implementing a project whose team is made up of customer employees, and vendor consultants, there are to be honest many competing agendas in forming that team.  The customer wishes to keep costs down, and utilize the consultants for as few hours as possible and still get the job done.   The Vendor wants their consultants to be vital to the success of the project and to be key players, thus causing the customer to rely on the consultants for a longer period of time.

It’s all money driven from a management perspective.  However despite all that, often times the team members could care less.  Their goal set is always different than those worrying about contracts and costs.   The successful implementation of the project is what is the most important to both consultants and customer employees.   So no matter what the overriding agenda is from management, typical team dynamics are always the same as if everyone worked for the same company.

So given this, why aren’t more mixed implementation teams using Agile development rather than the Waterfall method?

From my experience, teams aren’t using Agile for a few key reasons.

  • Change – Customers and Vendors do not want to change how they have been structuring contracts for years, which they view as a tried and true method.
  • Having two deliverables; Requirement Study, and Finished Product, is much easier to manage than having many deliverables. (Sprints)
  • A perception by the customer that using the Agile methodology will result in longer project times, and therefore higher costs paid to the vendor.
  • Worry by many that the overall goal set of the project is not understood with the Agile methodology so you can’t properly estimate the overall cost of the project.
  • Trust – Most managers do not trust vendor provided consultants.
These are all valid concerns, so how do we in the software industry alleviate them?

I think it is going to take a little more than just getting a few more evangelists into our industry.    Most of the above points deals with fear and trust.  Fear that something might not work is most often times more important than the know ledge that something won’t exactly work well.   So how do we as developers, implementation experts, project managers, and sales people convince the customer and our own vendors to accept this new way of doing it?    First and foremost I believe it’s up to the project teams to prove to management and sales that this  leads to happier customers.   Happier customers tend to purchase more products, and likely will invest in more services as well.   Secondly, we have to begin to think differently.  It is so easy to fall back on the old “document what your going to do, then go do it philosophy” that thinking in the Agile mode becomes an after thought.

So how to we as project teams begin to think differently?

I think it’s important that we all come to some consensus that software development and architecture design is not a process that has been perfected over thousands of years.   It’s a relatively infantile field in regards to physical construction disciplines in that one can say it’s only been around for 60 some years, and that improvement is possible.

If we all agree to this philosophy, then maybe we can begin to feel as if improvement can be made, through a new more flexible methodology.

Also I think it’s important to fully grasp the concept of what Agile is and how it improves team work, and better more directed delivery of solutions.

I would also recommend reading anything by Scott W. Ambler of IBM.  The guy is a very good speaker and accomplished writer.

see, you don’t get any of my responses from yahoo pidgin

Tags: , ,
Comment

Software Development Is Not Like Building a Car – Part II

Filed under: Emotional Intelligence, Project Management — Leave a comment
July 11, 2009

The most common questions asked by my peers and managers regarding Agile software development is this.  What is it, how can it benefit me, and how can it cut my costs down?

So what is Agile Software Development?

Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. The term was coined in the year 2001 when the Agile Manifesto was formulated.  – Wikipedia on Agile Software Development

What this means is this.  The Agile methodology allows for the design and construction of software to be more nimble and accepting of change.   As requirements change, people change, or business needs change over time, the team can refocus it’s effort on a new goal, more aligned with the strategic plan of the organization.   Like a military unit in war, when the general says march to point A initially, but then when you’re half way there, says march to point C instead, this methodology allows for development teams to have the flexibility to operate in the world in which businesses operate today.  It’s hard to plan 12, 24 or even 36 months out, because in most instances knowledge of what business environmental factors will be in place that far out is so unknown.

There are many specific agile development methods.  Most promote development iterations, teamwork, collaboration, and process adaptability throughout the life-cycle of the project. – Wikipedia on Agile Software Development

When we describe teamwork during an Agile methodology construction, we do not just mean the teams of developers and their project managers.   We also mean the stakeholders, and the end users as well.   Constant feedback, and involvement from these people, the key consumers of the end product, will help the development team drift closer to a successful, useful, and better aligned system.

What about costs?

Costs are a little different for the Agile methodology.  One must not think in terms of long term project costs, though this is somewhat  important, but the cost it takes to build each component, and if it is better to spend money one step at a time, with concrete results or simply write one big check and wait.   The difference between Agile and Waterfall regarding costs, have to do with what needs to be asked for up front.   The typical Waterfall project will go through these steps;   obtain a general idea of how long the project will take, and projection of costs.  Go ask for funding.   Start the project by doing a requirements gathering.  If this changes the length of the project go ask for more money.  If money is granted, then the teams begin the process of design, implementation, verification, and maintenance.    At any point in time, if the team runs out of funding, they will go with hat in hand and ask for more funding.  Each time funding is requested, the requester has nothing to show for the other monies that have been spent, except to say we are making progress.  Often times  a project plan will be used to illustrate progress, which will represent a virtual set of goals, with graphs showing estimated tasks, and percentage completion   This is a lot different than building a house or a car or a bridge.   A consumer of these products can see and touch them so even without being an engineer of any kind, they can make a judgment about progress.  If a bridge is half done, the consumer knows it’s not yet safe to use, but it looks like it’s half done.  If a car doesn’t have it’s engine yet, but it has a body, and 4 wheels and a steering wheel, consumers know this car can’t run but the construction teams are making progress.

In software development a stake holder needs to see screen, flow of data, or movement of parts to feel as if progress is being made.    Agile unlike Waterfall lends itself to this, by breaking the project down into iterations, which involve creating a concrete benchmark that will be achieved within the given time line, then acting upon that.   At the end of each iteration the stakeholders and end users can be shown real progress.    If the end result does not meet the new business reality, because the iterations tend to be short lived time frames and tackle small chunks of the overall system, it’s very easy to adjust the iteration’s work product.

The Agile methodology allows for project finalization to occur at the end of any iteration.  But unlike the  Waterfall method, at the end of each iteration you typically have a working product.   It might not be what was originally envisioned, but it is never the less a working system.   This allows the stakeholders to choose between funding additional work or going live with the product as it stands at the end of the iteration.   That flexibility is key to controlling costs with Agile.   I believe it’s better to allow your customer (and stakeholders are our most important customer) to be free to make that choice.

So if you’re a consulting organization, how can this work?

To be continued….

Tags: , ,
Comment

Software Development Is Not Like Building A Car – Part I

Filed under: Emotional Intelligence, Project Management — 3 Comments
July 10, 2009

I was at a meeting Wednesday with a bunch of really bright software architects discussing the concept of what engineering discipline most resembles software development.   We used home building as our most common point of discussion, and the debate got pretty heated.   The speaker – Jesse Tilly – was trying to convey to us that software unlike physical construction, takes place in a virtual world.  With abstract concepts, systems modeling, and eventual system construction the developer will develop an entire working system that the end user will never be able to touch or feel.   Systems are often responsible for moving, or manipulating data, making calls to other abstract systems in which some form of business logic is applied, or are responsible for controlling a physical component.    In most cases this is just a matter of transferring or manipulating 1′s and 0′s, and because of this and a “development environment” the software developer can often take many chances during the construction of a system that the physical engineer cannot.   Jesse at one point used the phrase, “how many times have you tried something to see if it worked.”   The answer of course is often, because when I or any other developer tries something to see it’s merit or validity, money isn’t wasted – unless tried in production – which is often avoided.

With good version control, it’s trivial to roll back to before something was tried.   To contrast this with a physical engineer; If Aerospace engineers decided to simply try something on a test flight, the pilot might end up meeting his maker sooner rather than later.

Well this did not sit well with a few of my fellow architects.   Mostly those that view what they do as a bit more like physical engineering than it really is.  I love software design a great deal so don’t get me wrong there.  Our systems are vital in our society, as they control everything from an MRI machines and Titan Rockets to your Microwave.   But with that said, with a few exceptions our discipline typically does not deal with the physical world.

Our most pressing issue is money.   How much is this going to cost?  How can I do it cheaper?   What’s the shortest and quickest way to get to point B?   This driving force of software development, I think was the point most missed in our meeting Wednesday.   In software development today, 90% of the time it is run by business decisions and not engineering principals.  So often times the cost benefit analysis overrides peer reviews, and proper techniques.

I think the largest reason for this, is because of the inflexibility of our current most widely used software construction methods.   The stakeholder would fund the project, higher the participants, be involved in the initial requirements studies, then go away for months and sometimes years waiting for the final delivery.   Often times during that project time line, the requirements would change, people would move off the project, and the initial understanding of requirements would be lost anyway.   The most common method still in use today is the waterfall method.  This method is one software engineers have borrowed from the physical engineering trade; think blue prints, plans, concrete, steel, wood, etc.   In the physical world, teams of engineers or architects, get together, design what it is they are going to build, plan out the steps to build it, then allow the construction teams to go to work.

Why does this work in the physical world?  This works because those involved are dealing with concrete ideas, and scientific laws and theories.  The requirements for a car are straight forward.  Does it run?  Does it carry passengers.   What about an airplane?  Does it fly?  Does it carry luggage?     Not to minimize the design and creation of these two products but in both instances even though people are the final consumer of these items, most of the time their input is the least important.   Take a car for example, the job of the driver is to turn left and right, to break, to accelerate and decelerate, and to control the radio.   While that is going on, thousands of parts are involved in making that car go where the driver wants it to go, by compensating or dealing with the laws of physics.

However in software design it’s all about people.  Now I realize I said earlier that a person cannot physically touch the end product of software design.   While this is a true fact, software does interact with people on a different level.  It’s all about guessing how a user will think and anticipate how they will most likely interact with the final product.    This is a lot harder, than any physical construction portends to be, and is an ongoing process. How do you as a software designer, or programmer anticipate how someone will think.   If your user base is more than 1 user, you opinion base grows.   You could code a screen one way and user A would be extremely happy, but user B would be turned off, and possibly move on to another choice.

This leads us to the questions that Software Development is asking today.   How do we get User A and User B, along with the stakeholder to be more involved in the final product? How do we generate a system that is closer to the requirements at the time of delivery?  How do we continue to encourage the stakeholder to continue funding?

Enter Agile.

To Be Continued…..

Tags: , ,
Comment
Follow

Get every new post delivered to your Inbox.