Digital is big. It is not only big in the size of the hype it created but also big in its breadth and impact. It has become the codename for anything mixing the latest in technology with dazzling customer experience. Wikipedia’s definition of digital transformation refers to it as the next chapter in technology literacy where technology amalgamates with creativity and innovation.
Continue reading Digital Thinking
Bimodal IT has lately become one of the hottest topics in the IT. In fact, if this is the first time you are hearing about Bimodal IT, you are more than a year late to the discussion.
There are lots of good resources describing what Bimodal IT is (E.g. this one, or this one) and likewise a plethora of flaming discussions why it is a good idea especially for digital or a bad one if not the worst.
I, on the other hand, see myself at the same distance to both parties. I believe, Bimodal IT is not a state you would be targeting nor a one you should avoid at all costs. Bimodal IT can be used as an interim model on the way to reaching IT nirvana.
IT organisations are large organisations consisting of numerous subunits which are constantly forced to change in all directions under the crossfire of new business requirements, changing market demands, emerging technologies, governance, risk and compliance concerns et al. It is therefore understandable, in fact inevitable, that each subunit of the organisation follows a different path, works with a different timetable and targets a different ideal state. In fact, I also find the similarity of the term Bimodal to Bipolar interesting, where Bipolar is used to describe a mental condition which is somewhat pertinent to what Bimodal states.
Bipolar Disorder is a form of major affective disorder, or mood disorder, defined by manic or hypomanic episodes (changes from one’s normal mood accompanied by high energy states).
Continue reading Surviving Bimodal IT
This is not a blog post about an emerging technology or a hot off the press IT trend, but just some notes about one of the pillars of every successful architecture work: Reference Architectures. This one explains what reference architectures are and why and how they are used in solution architectures.
Continue reading What are Reference Architectures?
Designing something from an idea or as in many cases from a problem that needs to be solved is surely an exciting but not always an easy process. We architects have to make sure we design the best possible solution meeting all the business requirements while adhering to global and organisational design best practices. One challenge we commonly face is incompletely or ambiguously expressed requirements which turns the analysis process into solving a rubik’s cube problem while skydiving. Furthermore, as we architects are mostly the middleman between business teams and technology units, we have to carefully manage the perceptions and expectations while using the relevant language to our audience. And we have to do all of these within a deadline and a budget while ensuring enough level of security and compliance, performance and fault tolerance etc.
Continue reading Learning magic from the “real” architects
Continue reading The Return of the Digital
It is true that SOA has lost a lot of its steam now and the craze of SOA has been overtaken by the charms of new disruptive digital forces namely cloud, big data, social business and mobility. As with every emerging technology climbing up to the peak of the hype cycle, those digital forces are fully loaded with promises and expectations but it is only a matter of time that they will crash into the harsh wall of reality. This story is not new, and has also shown itself in the “SOA is the savior” era. The goal of this blog is to remember that story once again and come up with a list of lessons learned, which might hopefully guide architects and implementers of the new digital forces.
Continue reading Implementing Disruptive Technologies: 8 Lessons Learned from SOA
Apart from tracking dependencies between SOA elements and managing the service life cycle, one of the indispensable tasks of SOA Governance is to control and manage SOA success. Successful implementation of a service architecture can be measured via certain indicators, also known as the Critical Success Factors (CSF). Every SOA adoption initiative should incorporate a step, ideally right before the architecture blueprinting phase, where unique success factors regarding the adoption are defined. This step should also outline the tools and techniques to be used in monitoring the success factors and together they should form the CSF Specification. CSF Specification could also be refined and improved throughout the adoption process to conform with common Enterprise Architecture(EA) practices.
Below, you can see a list of generic SOA CSF, with hints on how they can be monitored with SOA Governance:
Continue reading Monitoring SOA Critical Success Factors
I have started soa-tr in 2007 and tried to explain the bits and pieces of SOA with my every post since then. It has also been an amazing experience for me to see how SOA refined itself in time and became an acknowledged supporter of business and IT innovation. Surely, a lot of emerging technologies showed up since 2007, each promising better business and new opportunities, SOA always remained as the enabling force of business and IT alignment. Latest example being Gartner’s Nexus of Forces and the need for a more open and proactive IT.
Below presentation is my attempt to create a pile of information on the most important concepts around SOA for the avid SOA learner.
Continue reading A Comprehensive Introduction to Everything SOA