home architecture

Jumat, 02 Agustus 2013

Advanced Software Architecture Blog

Business Enablement through Release Management

Posted: 02 Aug 2013 08:54 AM PDT

Ever since IT became self-aware (no, not like Skynet in the Terminator) it has been striving to make itself more and more efficient. The "Aha!" moment for every IT organization comes when it realizes that business thinks it is too slow and delivers little value. After much introspection, new promises are made, commitment to customer service is renewed, processes are modified and streamlined, resources are trained, and so on… Everything runs great for awhile only to be repeated a couple of years later.

In the recent years, when the technology became more business user friendly, IT organizations realized that the best thing they could do for the business was to let it have a piece of the action. "Business Enablement" became the thing to do. The idea was to let the business users actually make changes to some parts of the IT systems. According to James Taylor, a thought leader in the decision management space, "business enablement means putting the business users, those who understand the business and how it needs to change, in a position to make the changes they want and need without IT being a roadblock."(http://www.ebizq.net/blogs/decision_management/2006/08/heres_a_quick_way_to_deliver_b.php)

Many organizations have struggled with enabling its business users in the way James Taylor describes it. Many have tried, yet many have failed. Those that are successful not only introduce the right technology solutions but also modify many of its processes to ensure that business users can actually do what they need with little or no IT involvement. Simplification and streamlining of the processes, automation, and modernization are the keys to a successful business enablement initiative. Introducing the right business enablement technology is, of course, beside the point.

Typically, the biggest obstacle to making business enablement work well is the IT Release Management process. It is often too rigid and cumbersome, requires a small army to execute, and takes a long time. Business doesn't want to wait months for its often simple changes to be moved to production. This is not what business enablement is all about. Yet, IT, rightly so, doesn't want to let anything get into production without proper testing and validation. And here, at these crossroads is where most business enablement initiatives die.

But there is a way to solve this… The simple solution is to provide a shortcut to production for most if not all the changes made by the business. The diagram below depicts a high level process for achieving this.

It really doesn't matter what tools are employed or what types of changes are made. This process should be able to handle most situations. The idea here is simple. To streamline the movement of business artifacts from development to production, several steps need to be taken.

Establish a Business Development Environment, a location where business users can make changes to elements of IT systems under their control and test the impacts of these changes
Once the changes are ready, provide an automated way to execute as many regression tests as necessary to validate that the changes do not impact any existing systems
Enable an automated way to execute performance / load tests to ensure that changes do not adversely impact established NFRs
Ensure stakeholders validate that the changes do not break current systems' functionality
Upon successful completion of all the tests, provide an automated way to deploy changes to production

Ideally, this process should take a few hours, a couple of days at the most. It should shortcut the existing Release Management process that normally takes weeks to complete. The goal is to introduce changes into production as quickly as possible. Of course, not every change is eligible for such first class treatment. The basic guiding principles for a shortened release management lifecycle should be:

If a change is confined to business owned elements only and no changes by IT are needed, the change is eligible for the streamlined release
If any IT changes are required, the regular release management process should be followed

While this process is simple from a high level perspective, there is a lot of hard work that needs to go into it to make it operational. Automation of testing and release management functions is never simple, fast, or straightforward. It usually takes months or even years to reach a point where it will cover 80% of IT systems and business functions. Yet, without automation, the process as described above cannot work. There is not going to be anything fast or streamlined about manual testing of business changes. On the other hand, the culture change required to make this process work can be daunting. Not many IT organizations will be willing to make this kind of a leap.

Business enablement can be achieved without a streamlined release management process. However, business agility cannot. Businesses cannot move as quickly as they can and react rapidly to a changing business climate without a way to introduce changes to IT systems in days rather than months. Those that can leverage business enablement and release management processes to their advantage will inevitably come out ahead.

Jumat, 19 Juli 2013

Advanced Software Architecture Blog

Achieving True Business and IT Partnership

Posted: 18 Jul 2013 07:50 PM PDT

Business and IT have a long history of conflict. Ever since computers became available to solve business problems and formalized IT organizations were created to support this mission, business and IT groups found themselves at odds. How often have we heard these statements?

"Business' expectations are unrealistic"
"All business cares about is dates"
"Business doesn't understand how IT operates"
Or…
"IT never delivers anything on time"
"IT can't deliver anything for less than $100K"
"IT processes are too complex and get in the way"

We know that the best way to deal with this conflict is to establish a true partnership between business and IT organizations. Yet, few companies are successful in achieving such symbiotic relationship. Why? There are many reasons for this. However, none is more relevant than IT's desire to control the entire software delivery lifecycle. No, your eyes do not deceive you. I indeed contend that many problems will be solved if IT gives up some control over how software is delivered into production.

I can hear the accusations of heresy right now. I can feel the wrath of IT purists enraged with such preposterous ideas. I can hear IT managers grinding their teeth in response to business infringing on their domain. Hold your angry rhetoric for just a bit longer. I will explain my reasoning shortly.

In this day and age, software packages have become so sophisticated that more and more features are aimed at non-IT people. Many systems include rules engines, BPM capabilities, scripting languages, etc. IT no longer has to reinvent the wheel to provide business the features it needs. As I argued in my earlier post, Death of Custom Software Development, IT organizations have to become more and more integration rather than custom development focused.

This argument can be extended further. IT no longer has to control the entire software delivery lifecycle. Enable the business to make changes to rules, processes, static values, web pages, printed communications, etc., and you will enter a brave new world of true partnership. It's that easy! Let the business control its own domain with minimal support from IT and let IT control the technology and infrastructure. The two will intersect when they truly need each other. IT will start playing a true supporting role by enabling the business to be productive and ensuring that changes business is about to introduce will not have a negative impact on everything else. Business will start looking at IT as an enabling partner, not just an expensive scapegoat. Everyone will hold hands and sing Kumbaya.

Of course, a lot needs to be done to achieve this Utopian society. Roadmaps need to be created, reviewed, and approved. Next generation packages need to be procured and implemented. Business users that will be empowered to make changes will need to be identified and trained. Significantly simplified and streamlined release management processes need to be created. Culture needs to change.

It is a long and arduous journey, but it is well worth the effort. Think about how much work IT does today that should really be done by the business. Let the business finally be the master of its own domain. And for the first time in many years, business will have no one but itself to blame for defects and missed deadlines!

Selasa, 30 April 2013

Advanced Software Architecture Blog

Death of Custom Software Development

Posted: 29 Apr 2013 09:49 PM PDT

(Disclaimer: This post is largely based on an excerpt from the upcoming book from Thomas Erl's Service-Oriented Computing series, Next Generation SOA: A Real-World Guide to Modern Service-Oriented Computing.)

Until very recently, the typical approach for many corporate IT departments when dealing with a business problem has been – code first, ask questions later. Many enterprise systems have been custom coded in the past. But this trend is changing. Companies realize that biggest value is gained from leveraging existing vendor or cloud-based solutions and integrating them into useful business solutions.

The transformation from a development to integration mentality moves companies up the maturity curve significantly. Agility is gained by purchasing or leasing the necessary foundational capabilities and customizing them to meet business needs. IT no longer spends majority of its time building solutions, finding bugs, and deciding which SDLC is better. Instead, IT teams can concentrate on delivering business value.

Organizations that adopted the integration first mentality are also forced to determine their competitive advantage strategies. Michael Porter identified three types of business capabilities that should be considered in designing a business strategy. They are base, competitive and differentiated capabilities. Base capability is one that is foundational to the business, without which a business cannot operate. This includes accounting, finance, HR, etc. as well as basic customer facing capabilities that are taken for granted. Competitive capabilities are those that allow companies to remain competitive with each other. For example, banks typically match each other's lending products, interest rates, depository vehicles, etc. Differentiated capabilities allow companies to stand out and separate themselves from each other. In banking, examples of this include bill pay features, innovative product offerings, customer service, etc. Michael Porter argued that companies want to be as good and efficient as its competitors in the base and competitive capabilities, but they want to excel in the differentiated capabilities to win. Investment strategies should also match this philosophy. Minimal necessary investments should be made in base and competitive capabilities that allow businesses to remain on par with others, but maximum possible investment should be made into increasing the degree of differentiation.

IT investment strategies should match those of its business partners. Therefore, IT should consider which capabilities its investments support. Just as with the business side, IT should minimize its spending on base and competitive capabilities and maximize spending to support differentiation. The coding and integration strategies are also impacted by these decisions. While base and competitive capabilities should almost never be custom coded, differentiated capabilities can, and oftentimes, should be. In the modern world, however, custom development most often takes shape of configuration or scripting, as in business process design, business rules development, and vendor package configurations. Little room is left to coding new functionality from scratch.

Service-orientation becomes a significant factor when companies adopt an integration mindset. It becomes the central theme of everything that happens within an enterprise. IT assets become a loosely coupled collection of vendor products, SaaS, services, mashups, and legacy applications. Service-oriented middleware and SOA governance become key players in every project, initiative, and program.

Finally, the company's entire culture must change. Everyone, from business and IT leadership to sales people and developers, must embrace the integration first mentality. Without it, there will constant infighting between the development and integration clans. Philosophical battles will ensue. But if clear direction is given to the organization and business and IT stand shoulder to shoulder, there will be very little choice but to accept the change.

One CIO I worked for issued a very clear and concise statement of direction to his IT organization related to software development decision criteria: "Reuse before buy before build." Everyone understood and embraced it. The IT organization understood what decisions took priority over others. Business stakeholders started asking questions like "Are there software assets we can reuse for this effort?" and "What vendor solutions exist for this problem?" The entire organization adopted the integration first mentality as a result of the CIO's guidance.

While software development will never completely disappear, most IT organizations supporting mature businesses need to shift towards the integration first culture. Let's face it, IT groups are not in the business of software development -- they are in business of supporting their business. IT needs to concentrate on delivering business value, not building custom software!

Jumat, 31 Agustus 2012

Advanced Software Architecture Blog

The Architect Manifesto

Posted: 31 Aug 2012 11:49 AM PDT

Software architecture is a well defined profession. It was in existence ever since computers were first created in the 1940s and software needed to be developed for them. While it became more formalized only in the 1980s, the profession took huge steps forward in the last 30 years. Today, the world of software architecture includes such disciplines as Enterprise Architecture, SOA, integration architecture, system architecture, data architecture, security architecture, etc. Yet, despite all of its different facets, software architecture core practices, goals, and approaches remain the same across all of its disciplines.

There are several key principles that help us become successful as software architects. No matter what problems we face, no matter what types of solution we need to apply, no matter what technologies we use, these general guidelines should always be followed. This forms the basis for the Architect Manifesto.

My research indicates that there have been multiple attempts at defining an Architect Manifesto. None of them seem to have succeeded or gained traction. Yet, I am certain that we, as architects, need the guiding light of a set of principles that will guide us in everything we do. We already unconsciously understand and follow them, but a formal definition will strengthen and inspire us. This is my attempt at verbalizing what we already know and apply in everyday work – the Architect Manifesto.

We, software architects, guide the design and evolution of computer systems. We strive to achieve maximum value for our business partners through this work. We constantly discover better ways to architect systems. As a result, we have come to value:

Simplicity over complexity
Pragmatism over perfectionism
Thinking out of the box over applying the same approaches to every problem
Developing technology agnostic solutions over making technology driven decisions
Delivering solutions to the business problems over concentrating purely on technology deliverables
Looking at the big picture over getting too deep into details
Long term, strategic thinking over short term, tactical thinking

I would appreciate feedback from all of the architects out there to make this manifesto more complete and relevant.

Kamis, 05 Juli 2012

2Anchor

Happy Independence Day.

Posted: 04 Jul 2012 10:58 AM PDT

Happy Fourth of July! I hope everyone has a wonderful and safe holiday weekend. That stud up there in the middle had his last day in the US Navy yesterday. It was a good run, but we are officially out. Here's to going back to school and a non disposable income! Whoo!

Rabu, 27 Juni 2012

2Anchor

Husbands Say The Darndest Things.

Posted: 26 Jun 2012 11:05 AM PDT

"Your hair adds more mass to your face, when you wear it down."

Boy is this kid a charmer....he's lucky he's cute. This was said the other morning when I was finished getting ready for work. I still wore my hair down.

In his defense my grandpa used to say I looked pretty with my hair up. Ha.

Selasa, 26 Juni 2012

2Anchor

The Renting Blues

Posted: 25 Jun 2012 09:52 AM PDT

Lately we've had the renters blues over here. We have been renting since July 2008, and we are over it. Yet, we aren't officially ready to settle down. We've been looking at houses online, exploring new areas of Rhode Island, and of course Boston and New York are always in the picture. To buy or not to buy.....
Oh, I should probably mention that we aren't the handiest people in the world. I mean, we can put together furniture, from Ikea....and we've never mowed a lawn. So many it's just best we stick to a condo in a city......

And now I bombard you with what I want our house/condo to look like, if and when we buy one. Courtesy of Pinterest of course!