Realizing the Software Defined Enterprise

While Gartner seem to be the primary advocates of software defined everything, (SDx) it’s rather obvious that SDx is primarily focused on service delivery, infrastructure and networks. I give full credit to Jason Bloomberg for exploring software defined development and devops in his recent blog. [1] He merges SDx and Shift Left ideas saying,  “If we combine no-code with DevOps properly, we now have a way of abstractly representing working production software, including its functionality. Not just the limited-scope apps that some no-code platforms are best known for, but full-blown, enterprise-class applications – created from nothing but their abstract representations with the push of a button.”

Heady stuff! In fact Jason  dismisses any skepticism advocating high risk strategies as necessary for digital transformation, “Given the exponential pace of technology innovation all around us, the greater risk is that we miss the full significance of Software-Defined Everything and its impact on the digital enterprise – until it’s too late.”

Wise heads may be shaking at this point; many will remember early attempts at diagrams to code, computer assisted systems engineering, model based development etc. All of which work in a limited manner, but never achieved the level of capability that is necessary to support enterprise class environments. However it has been clear for some time that this is a realistic goal. The basic concepts were articulated by Jack Greenfield and Keith Short in 2004 while they were at Microsoft, described as the Software Factory – “the configuration of extensible tools, processes and content using a software factory template based on a software factory schema to automate the development and maintenance of variants of an archetypal product by adapting and configuring framework based components.” [2]

Where I part company with Jason is in his promotion of “no-code” as the primary ambition in conjunction with integrated DevOps. The software factory is a “low” code environment, unlike no-code environments under full control of the developer community, who codify common patterns to allow standardization and assembly of common code to perform repeatable tasks; establishing an exceptionally high quality and productivity environment customized for the unique needs of a specific enterprise. But the really big value adds are that the factory governs reference architecture compliance and facilitates evolutionary development, enabling continuous change in initial development and the operational state, because all artifacts are under management. That’s not the full story; there are some key principles that make this practical:
1. A formal reference architecture is required to allow full life cycle meta data management and standardization of delivered artifacts. Note here I mean reference as meta-objects. A key aspect of the reference architecture is that everything is delivered as a service according to defined behavioral and dependency policies that enforce separation of concerns at all levels and reduce dependencies.
2. Rigorous specification of business services and rules independent of implementation. (the abstract representations referred to above) that support test driven development and provide high visibility of intra-project dependencies.
3. Abstracted specification interface removes requirement for (UML or similar) modelling skills. Allows business or business proxies to be responsible for the specification task.
4. Design by contract establishes strong boundaries, visible dependencies and separation of concerns.
5. Automation of infrastructure and codification of exemplar patterns in common code using software factory concepts.
6. Late (generation time) bound technology, allowing open technology architecture (platforms and frameworks) and inheritance of architectural changes with minimal impact on functional code.
7. Design by exception – only new patterns require design. Regular patterns are already codified in the factory.
8. Seamless linkage with Continuous Integration, Test Automation and DevOps.
9. Scalable Agile delivery process uses managed artifacts to provide high visibility of dependencies.
10. Continuous modernization process enables evolutionary capability development and change.

Reading this list, you might be tempted to say, this is just model driven development, or limited code environment, or SOA code generation etc. But the sum of the parts is greater than the whole – it’s a new model which is inherently business driven, with clear separation of business specification and implementations and technology. We call it the Agile Service Factory. [3] Today it is being used to deliver very large scale, enterprise class modernization projects [4] with exceptional productivity and quality, and the outcomes are inherently agile business services and solutions.

References:
1.  Building the Software-Defined Digital Enterprise (Part 2), Jason Bloomberg
2.   Software Factories, Jack Greenfield and Keith Short, Wiley, 2004
3. The Agile Service Factory
4. White Paper: Modernization with Service Architecture & Engineering and the Agile Service Factory

The Bioingine.com :- On-boarding PICO – Evidence Based Medicine [Large Data Driven Medicine]

    Medical Automated Reasoning Programming Language environment [MARPLE] References:- On PICO Gold Standard  http://www.ncbi.nlm.nih.gov/pmc/articles/PMC3140151/ http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1069073/ Formulating a researchable question: A critical step for facilitating good clinical research Sadaf Aslam and Patricia Emmanuel Abstract:- Developing a researchable question is one of the challenging tasks a researcher encounters when initiating a project. Both, unanswered issues in current clinical practice or […]

Try a Little Failure

I saw this graphic on Linked-In a while back and saved a copy to remind me that innovation is a mistake-filled endeavor. No mistake is bad, if you learn from it.

In innovation circles we often hear the phrase "Fail Fast" as if it were a goal to get through the failure quickly so that you can get to the achievement that’s waiting just around the corner. But I prefer to use the term "Learn

Try a Little Failure

I saw this graphic on Linked-In a while back and saved a copy to remind me that innovation is a mistake-filled endeavor. No mistake is bad, if you learn from it.In innovation circles we often hear the phrase “Fail Fast” as if it were a goal to get thro…

Dynamic Enterprise Architecture Models

Enterprise Architecture Models provide value by capturing knowledge about the business strategies, the current and target enterprise, understanding and identifying the gaps between current and target enterprise architectures, and then planning a roadmap of initiatives to close those gaps. Often they seem only to be used as a repository of static detail such as landscape models, […]

Enterprise-architecture – a changes report

A couple weeks back I wrote a post about what I see as the current status for enterprise-architecture – where the discipline is right now, how it’s different in different parts of the world, and how some of the big

Leadership Patterns and Anti-Patterns – The Growler

Prior to starting my career in IT (twenty years ago this month…seems like yesterday), I spent a little over eleven years in law enforcement as a Deputy Sheriff. Over those eleven years my assignments ranged from working a shift in the jail (interesting stories), to Assistant Director of the Training Academy, then Personnel Officer (even […]

Single Point of Failure (Comms)

Large business-critical systems can be brought down by power failure. My previous post looked at Airlines. This time we turn our attention to Telecommunications.

If someone said you had to accept an unreliable electricity supply as the price of innovation in appliances, you’d laugh. #NotNeutrality

— Martin Geddes (@martingeddes) August 8, 2016

More misery for BT broadband users after new power cut. Looks like ‘no single point of failure’ is an alien concept. https://t.co/mOobFidWe4

— Chris Tripp (@ChrisJTripp) July 21, 2016

It would be interesting to know where the single point of failure was in their power protection plan. https://t.co/zuaTm1z4tK

— Robin Koffler MBA (@robin_koffler) July 21, 2016

2G and 3G data services from @EE are down after a power outage. Details: https://t.co/zEJFpgpl4n pic.twitter.com/vcUOkPVtet

— The Register (@TheRegister) September 2, 2016

Obviously a power cut is not the only possible cause of business problems. Another single-point of failure could be a single rogue employee.

That shows that management should look at automating network. Since Network is single point of failure. https://t.co/ND5UXtNntj

— Anurag Kaushik (@kaushikanuk) August 3, 2016


Gavin Clarke, Telecity’s engineers to spend SECOND night fixing web hub power outage (The Register, 18 November 2015)

Related Post: Single Point of Failure (Airlines) (August 2016)