Archive

Posts Tagged ‘enterprise architecture’

Starting The Agile Architect

April 16, 2010 Leave a comment

What’s an architect to do when the team goes Agile?

The Agile Architect is a project I’ve started with with Peter Wennerstein of Icon Innovations.   The inspiration came when the leaders on the project I’m working on decided we were going Agile and sent everyone to Scrum training.   The Vision is to give guidance and encouragement to all the architects out there who want to be a valuable part of Agile projects.  I’m putting together my experience as a leader in Software Development and long time Solutions and Enterprise Architect.  I’m teaming up with Pete because of his passion and talent for communicating with images, icons and multi-media.  I think we’re going to have a lot of fun with this and hope it really helps you on your journey down the path of becoming an Agile Architect.

If you are interested in this topic, please leave a comment to encourage me in this projects.

Thanks!

Read more…

In the Cloud, whose data is it?

November 17, 2009 1 comment

I just attended a promotional event by NetSuite in Sydney.

When I got back to the office and started speaking with a colleague about how interesting the NetSuite proposition is, he conveyed to me a horror story he had recently heard about a Cloud or SaaS Customer.  It was a small business who had all there business records / erp / gl in the SaaS application and for some reason decided it was time to move on to another solution.  Trouble came when they requested their data and the supplier said, “it’s not your data, it’s mine.”

Shock horror I thought.  This is supposed to simplify the world for SME’s but now they’re going to need a crack legal team to protect them from the evil cloud. I was a bit shocked at this prospect, so decided to do a little research – kind of a snopes or myth busters act on this loss of ownership of one’s vital business data in the Cloud.  Here’s what I found.

You cannot delegate responsibility

Read more…

Moving the conversation from point-to-point to SOA

November 3, 2009 1 comment

I’m currently working as the Architect on a large Calypso implementation. Integration with the surrounding systems is clearly critical to our success. As usual, we are under very tight time constraints  I am participating in recurring working groups where we are reviewing all the interfaces that currently exist and determining how we should replace them or reproduce them.

My continuous reminder of thinking in terms of Services is probably very frustrating for the Business Analysts in the room.  They of course are concerned that their task in the project plan says, “Write the Business Requirements Doc (BRD) for the Systems X to System Y interface by next week.”  They really do not want to consider the possibilities and try to think about this a little differently

.

It’s not about the SOA Stack

No offense to my friends at Tibco and WebMethods who sell the technologies in the SOA stack, but it’s not about your stack.  We bought the stack and we’re still not SOA.  Until we start people thinking about the interactions of systems as one providing a Service and the other Consuming it, we are still going to be implementing specialized point-to-point interactions on top of some very cool and expensive technology.

Stop thinking like an Architect!

I’m sure many of you’ve been in these same type of conversations where you go though the list of existing interfaces and ask, “do we still need this one?”  As we go through these, I keep trying to drive the conversation away from interfaces and towards looking at what Service does a given legacy interface provide for whom rather than say, “this interface must be built.”

“If we look at what’s going on in this interface and build it as a Service, then we can reuse it,” I tend to say.

Half way through one of the above sessions, one BA whom I’ve known a long time half jokingly grumbled, stop thinking like an architect! Because he did not want to re-scope or revise his BRD’s just for the sake of what to him appears to be technical purity or unnecessary elegance.

I persist though in my doggedly determined manner.  Ask them to humor me a little longer, “…bare with me, be patient, you’ll see,” I say.  The people in the team are willing, so we entertain my way of thinking a little longer.  Finally there comes the moment, where the lights come one.  We’ve moved on to another interface.  As we dig in, we discover that this other interface is performing nearly identical function as a previous one.  I can see the result almost immediately.  Very quickly rather than having two more interfaces, we start having one more Consumer of an existing Service.  When that reduces time required to finish the project, finally the project manager smiles and is glad someone recommended he add an Architect to his project.  Keep thinking like an Architect, he says.  As a matter of fact, can you teach my whole team to think like an architect?

Now I’m happy!  We’re on the way to SOA and we haven’t hat to boil the ocean.

 

Technical Debt Metaphor

October 27, 2009 Leave a comment

As an architect in financial markets, I love the Debt metaphor described in Martin Fowler’s Blog as attributes to Ward Cunningham.  A simpler version the metaphor is pay me now or pay me later.

The essence of the metaphor is, when you are faced with a design choice with a quick and dirty solution as one option and a more appropriate, but perhaps more expensive alternative, picking the former option is like borrowing money.  As with financial debt, you will likely pay interest along the way and ultimately pay the prinicple in the future.  The interest is the pain the team feals each time a change must be made to the quick and dirty solution.  The principle is paid when a proper solution is finally implemented.

I think most people clearly understand this trade-off.  Where I find the problem lies is in valuing the debt. So, how many times will we have to change this thing?  How much difference will it make?  How frequently will it fail as a result?  Is your proper solution really better than the quick and dirty one?

In order to make an informed decision about the trade-off between higher up front cost and the technical debt, we really do need to know the valuation.  The up front cost is generally well know and expressed in dollars and time to market.  The debt is expressed in qualitative terms like, error prone, hard to maintain, etc…

Applying the metaphor to Enterprise Archtiecture

Here Charles Edwards applies the technical debt metaphor to enterprise level as the Enterprise Technical Debt.   He goes on to say that if you could explain this to a business executive in these terms, you’ll be well on your way to justifying investment in enterprise architecture.

 

Culture of Communication vs a Culture of Fear

October 20, 2009 Leave a comment

Does your organisation have a culture of communication or a culture of fear?

This thought came to mind while I was having a discussion with a System Owner recently.  He wanted to establish a forum in which like minded people could share their experience on how they had solved various technology problems they faced.  Examples of these include how they achieved SOX compliance or high availability.

At first blush, this seems like a great idea.  Surely there are people in the organisation who are facing problems that have already been solved.  This forum will be a good chance to encourage reuse and help people develop their presentation skills.

What about the culture of fear?

There is a dark side to this well intended idea that came to mind.  What if someone presents their solution and we find that their solution is contrary to one of the myriad standards or strategies in the organisation?

In a culture of fear organisation, I imagine there will be someone in the room who shouts out that the solution is not strategic or non compliant.  Now that it’s in the open, the sharing team will be lined up and shot and the organiser of the forum reprimanded for instigating proliferation of non-compliance.

Perhaps that’s a bit of an exaggeration.

Eliminate the Culture of Fear

If you want more reuse and communication in your organisation, you need to eliminate the culture of fear.  People need to feel free to tell the truth about what they are doing without fear of reprisal.

Standards and strategies are valuable and important.  But we should be careful about the organisational impact of fear.  What happens when people stop speaking freely?

Maybe it’s time to apply Agile principles to Data Warehouse

September 11, 2009 Leave a comment

My colleagues and I have recently been searching for a the perfect Reference Data Model for Financial Markets. The reason for the search is to establish the common data model for our enterprise so a Data Warehouse can be built that will not have to change.

Like every other bank, we already have a Data Warehouse – or two… But like most existing Data Warehouses, it does not meet all requirements and it is too difficult to change.  Thus the natural inclination is build another.

Thinking a bit differently, the existing Data Warehouse at one point probably did meet business requirements.  But, perhaps the real issue is not that the model was wrong from the start.   Rather, the need for rapid painless change was not engineered into the solution.

Enter Agile

Much of the motivation behind Agile software development methods is to accommodate change.  Change is a constant.  If we accept there will always be change and we adopt methods that mitigate the risk and cost of change in our systems, we can reduce the time we spend on Analysis and Design.  Today we spend inordinate amounts of time on Analysis and Design because we have all been taught that Change is Costly so we better get it right up front.  This places tremendous stress on Business Analysts and Architects to produce extensive documents.

In the Data Warehouse domain, change to the data model of the Data Warehouse looks extremely painful because it affects so many things.  So, naturally we aim to get the data model right up front.  In the current project I’m looking at, the immediate requirements are not so complex.  However, because we want get the data model right for all future requirements we have made the analysis task massive.

But yesterday I woke up and it (literally) dawned on me that we need to apply Agile principles to this Data Warehouse project.  But, I’ve only applied Agile to Software Development.  I really was not sure what this meant.

Agile Data Warehouse

If you’ve got a little time it doesn’t take long to find what you’re looking for.  I’d come across Scott Ambler’s writing on Agile before and good old google reminded me by bringing the Agile Modeling and Agile Best Practices for Data Warehousing essay is just what I was looking for.

{Market}ecture vs Central Planning

August 29, 2009 Leave a comment

The term marketecture I got from a clever fellow at Queensland Treasury Corp who responded to one of my posts about applying free market principles to enterprise architecture.

A short time back I wrote about the merits of applying free market principles to Enterprise Architecture rather than the central planning model we generally see.  The premise of the post was, if central planning didn’t work for broader economies, why do we think it’s going to work for our large enterprises?

While I was working at Citigroup in the Global Architecture Team, one of our objectives was to identify duplicate capabilities and eliminate them.  While performing this task, there was a tendency to frown upon the development teams who had built this duplicate capability.  On the surface, this makes sense.  But as you dig a little deeper, you’d often find the duplicate capability had done the incumbant one better (at least).

My worry about punishing the duplication is that we were actually stifling innovation.  Innovation often comes when an ambitious person or team is determined to make things better.  There is almost always an existing capability that will be duplicated.

In the central planned process, only sanctioned or approved innovation can take place.  Those same ambitious innovators above are expected to present their case or idea to some planning committee who will prevent the innovation until they are satisfied it is totally risk free and will result in ROI for the company.

The primary problem with this is, those ambitious innovative types generally detest process and bureaucracy.  Next problem is, we cannot be certain that something innovative will succeed – until it’s been done at least once.

How can we have Marketecture

If we agree that innovation requires the freedom and suffers in a central planning environment, how do we do marketecture in an enterprise?

I think that’s grist for the next post.  If you have any thoughts or comments on this, please post a comment.